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Abstract 

Individual machines arc no longer sufficient to handle Ihe 
offered load to many Internet sites. To use multiple ma- 
chines for scalable performance, load balancing, fault trans- 
parency, and backward compatibility with URL naming 
must be addressed. A number of approaches have been de- 
veloped to provide transparent access to multi-server Inter- 
net services including HTTP redirect, DNS aliasing, Magic 
Routers, and Active Networks. Recently however, portable 
Java code and lightly loaded client machines allow the mi- 
gration of certain service functionality onto the client. In 
this paper, we argue that in many instances, a client-side ap- 
proach to providing transparent access to Internet services 
provides increased flexibility and performance over the ex- 
isting solutions. We describe the design and implementation 
of Smart Clients and show how our system can be used to 
provide transparent access to scalable and/or highly avail- 
able network services, including prototypes for: telnet, 
FTP, and an Internet chat application. 

1 Introduction 

The explosive growth of the World Wide Web is 
straining the architecture of many Internet sites. Slow 
response times, network congestion, and u hot sites 
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of the day" being overrun by millions of requests 
are fairly commonplace. These problems will only 
worsen as the Web continues to experience rapid 
growth. As a result, it has become increasingly impor- 
tant to design and implement network services, such 
as HTTP, FTP, and web searching services, to scale 
gracefully with offered load. Such scalable services 
must, at minimum, address the following issues: 

• Incremental Scalability - If the offered load be- 
gins to exceed a service's hardware capacity, it 
should be a simple operation to add hardware 
resources to transparently increase system ca- 
pacity. Further, a service should be able to 
recruit resources to handle peaks in the load. 
For example, while the US Geological Sur- 
vey Web site (http://quake.usgs.gov) 
is normally quite responsive, it was left com- 
pletely inaccessible immediately after a recent 
San Francisco Bay Area earthquake. 

• Load Balancing - Load should be spread dynam- 
ically among server resources so that clients re- 
ceive the best available quality of service. 

• Fault Transparency - When possible, the service 
should remain available in the face of server and 
network upgrades or failures. 

• Wide Area Service Topology - Individual 
servers comprising a service arc increasingly 
distributed across the wide area [Net 1994, Dig 
1995]. The server machines that comprise a 
network service should not be required to have a 
restricted or static topology. In other words, all 
servers should be allowed to arbitrarily migrate 
to other machines. 

• Scalable Service To Legacy Servers - Adding 
scalability to existing network services such as 
FTP, Te 1 ne t , or HTTP should not require mod- 
ifications to existing server code. 



Unfortunately, providing these properties for net- 
work services while remaining compatible with the 
de facto URL (Uniform Resource Locator) naming 
scheme has proven difficult. URLs arc by definition 
location dependent and hence are a single point of fail- 
ure and congestion. A number of efforts address this 
limitation by hiding the physical location of a par- 
ticular service behind a logical DNS hostname. Ex- 
amples of such systems include HTTP redirect, DNS 
Aliasing, Failsafe TCP, Active Networks, and Magic 
Routers. 

We argue that in many cases the client, rather than 
the server, is the right place to implement transparent 
access to network services. We will describe limita- 
tions associated with each of the above solutions and 
demonstrate how these limitations can be avoided by 
moving portions of server functionality onto the client 
machine. This approach offers the advantage of in- 
creased flexibility. For example, clients aware of the 
relative load on a number of FTP mirror sites can con- 
nect to the least loaded mirror to deliver the highest 
throughput to the end user. Ideally, the selection and 
connection process takes place without any interven- 
tion from the end user, unlike the Web today where 
users must choose among FTP mirror sites manually. 
Note that in this example, clients must take into ac- 
count available network bandwidth to each mirror site 
as well as the relative load of the sites to receive op- 
timal performance. Such flexibility would be difficult 
to provide with existing server-side solutions since in- 
dividual servers may not have knowledge of mirror 
site group membership and client location. 

The migration of service functionality onto client 
machines is enabled by two recent developments. To- 
day, most popular Internet services, such as FTP, 
HTTP, and. search engines are universally accessed 
through extensible Web browsers. This extensibility 
allows insertion of service-specific code onto client 
machines. In addition, the advent of Java (Gosling 
& McGilton 1 995] allows such code to be easily dis- 
tributed to multiple platforms. Next, network latency 
and bandwidth arc increasingly the bottleneck to the 
performance delivered to clients. Thus, client proces- 
sors can be left relatively idle. We will demonstrate 
<fhat offloading service functionality onto these idle 
cycles can substantially improve the quality of service 
along the axis described above. 
^ Motivated by the above observations, we describe 
the design and implementation of Smart Clients to 
support our argument for client-side location of code 
for scalability and transparency. The central idea be- 
hind Smart Clients is migrating server functionality 
to the client machine to improve the overall qual- 
ity of service in the ways described above. This ap- 



proach contrasts the traditional "thin-client" model 
where clients are responsible largely for displaying 
the results of server operations. While our approach 
is general, this paper concentrates on augmenting the 
client-side architecture to provide benefits such as 
fault transparency and load balancing to the end user. 

The rest of this paper is organized as follows. Sec- 
tion 2 discusses existing solutions to providing scal- 
able services. The limitations of the existing solutions 
motivates the Smart Client architecture, described in 
Section 3. Section 4 demonstrates the utility of the ar- 
chitecture by describing the implementation and per- 
formance of interfaces for telnet, FTP, and a scal- 
able chat service. Section 5 evaluates our require- 
ments above in the context of the Smart Client archi- 
tecture. Section 6 describes related work, and Sec- 
tion 7 concludes. 



2 Alternative Solutions 

Existing architectures include DNS Aliasing (Brisco 
1995, Katz et al. 1994], HTTP redirect [Berners-Lee 
1995], Magic Routers [Anderson et al. 1996], fail- 
safe TCP [Goldstein & Dale 1995], and Active Net- 
works [Wetherall & Tennenhousc 1995]. Figure I de- 
scribes how Smart Clients fits in the space of existing 
solutions. We will describe each of the existing so- 
lutions in turn leading to a description of the Smart 
Client architecture. 

A number of Web servers use Domain Name Server 
(DNS) aliasing to distribute load across a number of 
machines cooperating to provide a service. A single 
logical hostname for the service is mapped onto mul- 
tiple IP addresses, representing each of the physical 
machines comprising the service. When a client re- 
solves a hostname, alternative IP addresses are pro- 
vided in a round-robin fashion. DNS aliasing has been 
demonstrated to show relatively good load balancing, 
however the approach also has a number of disadvan- 
tages. First, random load balancing will not work as 
well for requests demonstrating wide variance in pro- 
cessing time. Second, DNS aliasing cannot account 
for geographic load balancing since DNS docs not 
possess knowledge of client location/server capabil- 
ities. 

On a client request, HTTP redirect allows a server 
to instruct the client to send the request to another lo- 
cation instead of returning the requested data. Thus, 
a server machine can perform load balancing among 
a number of slave machines. However, this approach 
has a number of limitations: latency to the client is 
doubled for small requests, a single point of failure 
is still present (if the machine serving redirects is un- 
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Figure I : This figure describes the design space for providing transparent access to scalable network services. 
Transparency mechanisms can be implemented in a number of places, including the client, network, network 
routers, or at the service site. 



available, the entire service appears unavailable), and 
servers can still be overloaded attempting to serve 
redirects. Further, this mechanism is currently only 
available for HTTP; it docs not work with legacy ser- 
vices nor does it optimize wide-area access. 

The Magic Router provides transparent access by 
placing a modified router on a separate subnet from 
machines implementing a service. The Magic Router 
inspects and possibly modifies all IP packets before 
routing the packets to their destination. Thus, it 
can perform load balancing and fault transparency 
by mapping a logical IP address to multiple server 
machines. If a packet is destined for the designated 
service IP address, the Magic Router can dynami- 
cally modify the packet to be sent to an alternative 
host. Unresolved questions with Magic Routers in- 
clude how much load can be handled by the router 
machine before the dynamic redirection of the pack- 
ets becomes the bottleneck (since it must process ev- 
ery packet destined for a particular subnet). Magic 
Routers also require a special network topology which 
may not be feasible in all situations. Finally, the 
Magic Router is not aware of the load metrics relevant 
to individual services, i.e. it would have to perform 
rcmappings based on a generic notion of load such as 
CPU utilization. 

Fail-safe TCP replicates TCP stale across two in- 
dependent machines. On a server failure, the peer 
machine can transparently lake over for the failed 
machine. In this fashion, fail-safe TCP provides 
fault transparency. However, it requires a dedicated 
backup machine to mirror the primary server, and it 
docs not address the problem of the front -end be- 
coming a bottleneck. Finally, both fail-safe TCP and 



Magic Routers are relatively heavy-weight solutions 
requiring extra hardware. 

Proposals for Active Networks allow for computa- 
tion to take place in network routers as packets are 
routed to their destination. This approach could po- 
tentially provide fault transparency and load balanc- 
ing functionality inside of the routers. We believe 
Active Networks, if widely deployed, can provide a 
mechanism for implementing Smart Client function- 
ality. 

All of the above solutions provide a level of trans- 
parent access to network services with respect to load 
balancing and fault transparency. However, they arc 
all limited by the fact that they are divorced from 
the characteristics and implementations of individ- 
ual services. We observe that the greatest function- 
ality and flexibility can often be provided by adding 
service-specific customization to the client, rather 
than service-independent functionality on the server. 

3 Smart Client Architecture 

In this section, we describe how the Smart Client ar- 
chitecture allows for the construction of scalable ser- 
vices. For the purposes of this paper, we assume the 
service is implemented by a number of peer servers, 
each capable of handling individual client requests 1 . 
The key idea behind Smart Clients is the migration 
of certain server functionality and state to the client 
machine. This approach provides a number of advan- 
tages: (i) offloading server load and decreasing imple- 

1 This assumption holds for many widely-used Internet services 
such as HTTP, FTP. and Web searching services. 
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Figure 2: This Figure describes the Smart Client service access model. Two service-specific Java applets are sup- 
plied to mediate server access. The client interface applet provides the interface to the user and makes requests 
of the service. The director applet is responsible for providing transparency to the client applet; it makes server 
requests to the appropriate (e.g. least loaded) server, and updates its notion of server state. 



mentation complexity, (ii) allowing clients to utilize 
multiple peer servers distributed across the wide area 
without the knowledge of individual servers, and (iii) 
improving the load distribution and fault transparency 
of the service as a whole. 

When a user wishes to use a service, a bootstrap- 
ping mechanism is used to retrieve service-specific 
applets designed to access the service. Two cooper- 
ating applets, a client interface applet and a direc- 
tor applet, provide the interface and mask the details 
of contacting individual servers respectively. Client- 
side functionality is partitioned in this fashion to sep- 
arate the service's interface design from the mecha- 
nisms necessary to deliver client requests to servers in 
a load-balanced, fault tolerant manner. 

The client interface applet is responsible for ac- 
cepting user input and packaging these requests to 
the director applet. The director applet encapsulates 
knowledge of the service member set and the service- 
specific mcta-in formation allowing the director ap- 
plet to send requests to the appropriate server. For 
every user request, the Smart Client uses the direc- 
tor applet to invoke a service-specific mechanism for 
determining the correct destination server for the re- 
quest. Figure 3 shows the interaction of the two ap- 
plets in a Java-enabled Web browser. A number of is- 
sues arc associated with this approach: naming mech- 
anisms for choosing among machines implementing 
a service, procedures for receiving updates with new 
information about a service (e.g., changes in load, or 
the availability of a new machine), and bootstrapping 
retrieval of the Smart Client applets. Wc will discuss 



each of these issues in turn leading to a description of 
the Smart Clients API. 

3-1 Transparent Service Access 

3.1.1 Load Balancing and Fault Transparency 

We begin our discussion of the Smart Client architec- 
ture by describing the techniques used to provide toad 
balanced and fault tolerant access to network services. 
Discussion of bootstrapping the retrieval of the Smart 
Client is deferred until Section 3.2. Wc assume that 
services accessed by Smart Clients are implemented 
by a number of peer servers. In other words, any 
of a list of machines are capable of serving individ- 
ual client requests. Thus, the director applet makes 
a service-specific choice of a physical host to contact 
based on an internal list of (dynamically changing) 
server sites. Ideally, this choice should balance load 
among servers while maximizing performance to the 
end user. 

While the choice of load balancing algorithm is ser- 
vice specific, we enumerate a number of sample tech- 
niques. The simplest approach is to randomly pick 
among service providers. While this approach is sim- 
ple to implcmemcnt and does not require server mod- 
ifications, it can result in both poor load balancing 
and poor performance to the end user. For example, 
an FTP applet picking randomly among a list of ser- 
vice providers may pick an under-powered mirror site 
on another continent. A refinement on random load 
balancing would bias future random choices based on 
how quickly requests to a particular server are pro- 
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( cessed. For services where multiple successive re- 
l quests are likely, we believe this technique should re- 
V suit in good performance while maintaining imple- 
\mentalion simplicity. 

Another technique involves maintaining service- 
specific profiles of servers. In the FTP example 
above, a description of hardware performance and 
network connectivity (perhaps using techniques simi- 
lar to the Internet Weather Report [Mat 1 996]) may be 
associated with each server. The Smart Client director 
r applet can then use this information to evaluate avail- 
able bandwidth to each server based on the client's 
i location. A further improvement requires maintain- 
ing load i nformation for each se jver. In this case, the 
client is able to maximize performance by weighing 
a combination of network connectivity, server perfor- 
mance, and current server load. 

The mechanisms used for load balancing can be 
"adapted to provid e fault transparency to the end use r. 
Techniques such as keep fl livr mm?fry nr t,rvw> ftl) <c 
can bc utilizcd to determinc server failurg. Upon fail- 
ureTTfic^direc tor applet canrcinvoke me load balanc - 
ing mcchanismto choose an alternate server and rea p- 
ply the request. By storing all uncompleted server re- 
quests aHd necessary client state information, the di- 
rector applet can connect to an alternative site to re- 
transmit all outstanding requests transparently to the 



user. 

3.1.2 Updating Applet State 

In order to make load balancing decisions, the client 
may need a reasonably current profile of the individ- 
ual servers providing the service. Depending on the 
application, updating the director of changes in ser- 
vice state can be achieved through cither lazy or ciCccm 
ffiftniquf s presenting h oth performance and scmag ^ 
t ic tradeoffs for maintaining consistency. 

Examples^ft^gcTjJ^tc^hniques include client 
polling an<(^rv^caUbacks^ client polling of 
servers to maTrfraiiT^ad rfflormatton has the disad- 
vantage of severely loading server machines. Server 
callback techniques can be more scalable than client 
polling, however they require server modifications 
and increase implementation complexity. Neither 
client polling nor server callbacks is likely to scale to 
the level of thousands of clients necessary for some 
Web services. Eager update methods arc appropriate 
when accurate information is required and the scale of 
the service is small enough to support eager protocols. 

Lazy update techniques [Ladin et al. 1992] are 
likely to be more appropriate in the context of the 
Web. Lazy updates reduce network traffic by sending 
information only occasionally, after a number of up- 



dates have been collected. One particularly attractive 
mode of lazy updates is piggy-backing update infor- 
mation with server replies to client requests. For ex- 
ample, a server can inform Smart Client directors ap- 
plets of the addition of new server machines compris- 
ing the service when replying to a director request. 

3,1.3 Director Architecture 

Smart Clients provide a very flexible mechanism 
for implementing service-specific transparency. The 
Smart Client director provides the illusion of a single, 
highly-available machine to the programmer of the 
client interface applet. Requests made by the Smart 
Client client interface applet are written to operate on 
a single machine. The director applet chooses the des- 
tination server based on service-specific information 
such as load, availability, processor speed, or connec- 
tion speed. 

The director accepts arbitrary requests of the form 
"perform this action on a server node". The direc- 
tor applet sends the request to the server determined 
to deliver the best performance to the client. If the 
request fails, the next server in the director applet's 
ranked list is contacted with the request. In this way, 
the director applet provides transparent access to arbi- 
trary server groups. As a result of the well-defined in- 
terface between the client interface applet and the di- 
rector applet (as described in Section 3.3), individual 
director applets are easily interchanged for many dif- 
ferent services. For example, the director applet pro- 
viding transparent Telnet access to a cluster of work- 
stations can also be used for services such as chat or 
FTP. 

3.2 Bootstrapping Applet Retrieval 

The goal of transparent access to network services 
would be compromised if the Smart Client applets 
necessary for service access must be downloaded 
from a single hostname before every service access. 
We have created a scalable bootstrapping mechanism 
to circumvent this single point of failure. To remove 
the single point of failure associated with a single 
hostname, we have modified jfox [Wendt 1996], an 
existing Java Web browser, to support a new service 
name space, e.g. service: //now chat service. For the 
service name space, the browser contacts one of many 
well-known search engines with a query. These well- 
known search engines serve the same purpose as the 
root name servers in DNS. 

Currently, the browser contacts Altavista [Dig 
1995] with a query requesting an HTML page whose 
title matches the service name, e.g. "now chat ser- 



vice". In this way, Smart Clients leverages highly- 
available search engines to provide translations from 
well-known service names to a URL. The URL points 
to a page containing a service certificate. The cer- 
tificate includes references to both the client interface 
and director applets. In addition, the certificate con- 
tains some initial guess as to service group member- 
ship. This hint initializes the director applet, allowing 
the applet to validate the list by contacting one of the 
nodes. Figure 4 shows a certificate used for the NOW 
chat service. 

Jfox has been extended to cache the Smart Client 
applets associated with individual services, the lo- 
cation of the service certificate, the certificate itself 
and any additional state that the Smart Client direc- 
tor needs for the next access to the service. While 
the client interface applet and service-certificate are 
cached using normal browser disk caching mecha- 
nisms, the director state is saved by serializing the di- 
rector applet (and any relevant instance variables) to 
disk using Java Object serialization [Jav 1996). Thus, 
on subsequent service accesses, the director applet 
need not rely on the initial group membership con- 
tained in the service certificate. Instead, it can use 
the last known service group membership. With this 
bootstrapping mechanism, no network communica- 
tion is necessary to load the service applets after the 
initial access. 

Currently, the service certificate and applets arc 
cached indefinitely. In the future, we plan on adding 
a time-out period to the server certificate. After the 
timeout, the browser can revalidate both its service 
certificate and the associated applets. If either the cer- 
tificate or applets are inaccessible, the decision to pro- 
ceed with the cached state can be made on a service- 
specific basis. 

Note that with the exception of bootstapping, 
the implemented applets work on unmodified Java- 
capable Web browsers such as Netscape Navigator 
and Internet Explorer. Further, mainstream browsers 
such as Internet Explorer allow for installation of fil- 
ters over the entire browser [Leach 1 996]. Such a fil- 
ler would allow our bootstrapping mechanism to be 
implemented in widely used Web browsers. 

The bootstrapping problem has been addressed in 
other contexts. For example, distributed applications 
need access to DNS without a name server. Such 
applications fall back to sending queries well-known 
root name servers when it is unable to resolve a host- 
name. As another example, applications which com- 
municate through RPCs must bind to a server without 
using an RPC. This problem is also addressed by us- 
ing broadcast to initiate binding to RPC servers on the 
network. 



<HTML> 

<TITLE>now chat service</TITLE> 

<META name =" description" content- "now chat service" > 
<META name*" keywords" content="now chat service"> 
< APPLET name«"now_chat" 

codebase«"Chat" code- "Chat .class "> 
<param name «" director" value«"now__chat_director" > 
</APPLET> 

< APPLET name* "now_chat_di rector" 

codebase- " Chat " code* "ChatDi rector . c lass " > 
< pa ram name- "nodes" 

value- "u81.cs. berkeley.edu, u8 2 .cs .berkeley.edu, u83 . ce.berkeley.edu" > 
</APPLET> 
</HTML> 



Figure 4 : This example of a service certificate references both the client interface applet (Chat.class) and the direc- 
tor applet (ChatDirector.class). Initial service group membership (u8 1 ,u82 and u83) is fed to the director applet for 
bootstrapping purposes. The director applet contacts one of these machines to obtain group membership updates. 



3,3 Smart Clients API 

In this subsection, we will describe the Smart Clients 
API. The goal of the API is to provide a generic in- 
terface for service providers to develop transparent 
access to their servers and to make it easier for pro- 
grammers to implement applications for distributed 
services. In the interests of brevity, wc do not doc- 
ument the interface in its entirety. Interested readers 
can download the Java classes implementing the API 
to see how the classes arc used to implement a number 
of sample applications (as described in Section 4). 

Figure 5 presents a high-level overview of the Java 
methods which make up the Smart Clients API. The 
IDi rector interface provides a simple abstraction 
of a service to the application programmer. The pro- 
grammer makes director requests through the IDirec- 
tor interface. The requests are then sent by the direc- 
tor applet to one of the service nodes; note that the ap- 
plication programmer is not concerned with managing 
server nodes. If the request fails, a director exception 
is raised. In response, the director will first allow the 
request to clean up any state, then resend the request to 
another server. The director applet takes a best effort 
approach in delivering the request. Thus, a return of 
false from the delivery request indicates a catastrophic 
failure of the service, i.e. all servers have failed. 

4 Sample Applications 

4.1 Telnet Front-End for a NOW 

The NOW (Network of Workstations) Project [Ander- 
son et al. 1995a] at UC Berkeley provides approx- 
imately 100 workstations for use within the depart- 



ment; however, it is difficult for users to know which 
of the 100 machines is least loaded. To address this 
problem, we developed a Web page containing a sin- 
gle button which, when pressed, opens a telnet win- 
dow onto the least loaded machine in the NOW clus- 
ter. 

The implementation of the telnet application is 
straightforward. The telnet Web page encapsulates 
the necessary Smart Clients applets. The director ap- 
plet periodically polls the NOW's operating system, 
GLUnix [Ghormley ct al. 1995], to retrieve the load 
averages of machines in the cluster through a simple 
Common Gateway Interface (CGI) program. When 
the user clicks on the telnet button (provided by the 
client interface applet), a request is sent to start a tel- 
net window on the least loaded machine in the cluster. 
I f the directo r applet notic es thaU jrnflchinr ^ t*\\t>A 
i t will nprsliblTrtrteTnd rcqueststo that node. ^ We 
are currently investigating a fault-tolerant telnet ser- 
vice which re-opens a telnet window (with saved stale 
such as the current working directory and environ- 
ment variables) in the event of node failure. The fault- 
tolerant telnet would pass this saved state through the 
RequestException object (as described in Fig- 
ure 5. 

4.2 Scalable FTP Interface 

We have also used Smart Clients to build a scalable 
frontend for FTP sites. As a motivating example, 
the Netscape Navigator FTP download page 2 con- 
tains twelve hyperlinks for netscape FTP hosts. Users 
choose among netscape sites or mirrors to perform 

2 http: //www. netscape .com/comprod/mirror- 
/client.download . html 



// Interface to encapsulate all client interface applet requests 

public interface IRequeet { 

// Downcall from the director to the request object. Perform the action 

If on 'hostname' . Throw RequestException if an error occurs 

public void action (String hostname) throws RequestException; 

// Downcall from the director to the request object upon failure. Perform 

II any necessary cleanup code. The state of the failed request consists 

II of the 'oldhostname' and the RequestException that was thrown from the 

II action method 

public void cleanup (String oldhostname, RequestException t) ; 

} 

// Generic interface for all director applets 

public interface IDirector { 

// Execute the request r on a hostname of the director' s choosing. If the 
II request object throws a RequestException, assume failure of the node 
II and reapply the request after calling the request's cleanup method. 
II If there are no remaining nodes, return false. Otherwise, return true. 
public boolean apply ( IRequest r) ; 



Figure 5: This Figure describes some of the interfaces in the Smart Clients API. Classes 'that implement the di- 
rector interface have been written to provide much of the functionality necessary to simple directors, including 
randomized directors (picking a random machine) and directors based on choosing the least loaded server. 



manual load balancing. To improve on this interface, 
Smart Client applets present a single download but- 
ton to the user. The client interface applet delivers re- 
quests to the director to retrieve a file, while the di- 
rector picks a machine at random from a static set of 
nodes. When the user presses the button, the applet 
transparently determines the best site for file retrieval. 

To demonstrate the scalability available from us- 
ing Smart Clients, we measure delivered bandwidth 
to Smart Client applets running in Netscape Navi- 
gator from a varying number of FTP servers. We 
emphasize that the choice of FTP site is transpar- 
ent to the end user (a single button is pressed to be- 
gin file retrieval) and that our FTP application can be 
downloaded to run with unmodified servers and Java- 
compliant browsers. The tests were run on a cluster 
of Sun Sparcstation 10's and 20's interconnected by a 
10 Mbps Ethernet switch. The Ethernet switch allows 
each machine in the cluster to simultaneously deliver 
10 Mb of aggregate bandwidth to the rest of the clus- 
ter without the the contention associated with shared 
Ethernet networks. Either one, two, or four of the ma- 
chines arc designated FTP servers, while the rest of 
the machines in the cluster attempt 40 consecutive re- 
trievals of a 5 12 KB file. This experimental setup ap- 
proximates multiple FTP mirror sites spread across 
the wide area. 

Figure 6 summarizes the results of the FTP scal- 
ability tests. The graph shows aggregate delivered 



bandwidth in megabytes per second as a function of 
the number of client machines making simultaneous 
file requests. For one FTP server, 8 clients are able 
to saturate the single available Ethernet link at 1.2 
MB/s 3 . The results for two and four FTP servers 
demonstrate that the random selection of an FTP 
server used within the applet delivers reasonable scal- 
ability. Sixteen clients are able to retrieve approxi- 
mately 2 MB/s from two servers, while 16 clients sat- 
urate four servers at approximately 3 MB/s, 

For small number of clients, a single FTP server 
demonstrates the best performance because all 40 file 
downloads are made during a single connection. For 
the multi-server tests, multiple connections and dis- 
connections take place as the clients attempt to ran- 
domly balance load across the servers. In the fu- 
ture, this problem can be avoided by implementing 
site affinity with successive file requests (if deliv- 
ered bandwidth on the previous was deemed satisfac- 
tory), implementing a load daemon on the nodes to al- 
low the clients to continuously choose lightly loaded 
machines, or by using services such as the Internet 
Weather Map [Mat 1 996] to choose low-latency hosts. 
This information can be used to incrementally scale 
connections to available FTP servers (i.e. allow some 
machines to be recruited only when needed). 

3 We were unable to take measurements for more than ] 6 simul- 
taneous clients making requests to a single server because the FTP 
server would not allow more than 16 simultaneous file retrievals. 
We plan to investigate this limitation further. 




Figure 6: This figure demonstrates how a Smart Client interface to FTP delivers scalable performance. The graph 
shows delivered aggregate bandwidth as a function of number of clients making simultaneous requests. 



43 Scalable Chat 

The next application we implement is Internet chat. 
The application allows for individuals to enter and 
leave chat rooms to converse with others co-located 
in the same logical room. The chat application is im- 
plemented as Java applets run through a Web browser. 
Figure 7 depicts our implementation of the applica- 
tion. Individual chat rooms are modeled as files ex- 
ported through WebFS [Vahdat et al. 1 996], a file sys- 
tem allowing global URL read/write access. WebFS 
provides for negotiation of various cache consistency 
protocols on file open. 

Wc extended WebFS to implement a scalable 
caching policy suitable to the chat application. In 
this model, when a user wishes to enter a chat room, 
the client simply opens a well-known file associated 
with the room. This operation registers the client 
with WebFS. Read and write operations on the file 
correspond to receiving messages from other chatters 
and sending a message out to the room, respectively. 
On receiving a file update (new message), WebFS 
sends the update to all clients which had opened 
the file for reading (i.e., all chatters in a room). In 
this case, the client interface applet consists of two 
threads, a read thread continuously polling the chat 
file and an event thread writing user input to the chat 
file. These read/write requests are sent to the chat 



server via the director applet. 

The director sends the request to the hostname that 
represents the best service node at the time. If the re- 
quest does not complete, the request raises an excep- 
tion to the director applet. The director applet then 
calls the service-specific cleanup routine for the re- 
quest, and rcsends it to another service node. Note 
that the request takes a service specific failure event, 
such as chat file not found or WebFS server is down, 
and translates it into a general exception. Thus, the di- 
rector applet can be written for a cluster of machines 
and reused for many different protocols: FTP, Telnet 
and chat. 

From the above discussion, it is clear that a sin- 
gle WebFS server can quickly become a performance 
bottleneck as the number of simultaneous users is 
scaled. To provide system scalability, wc allow multi- 
ple WebFS servers to handle client requests for a sin- 
gle file. Each server keeps a local copy of the chat file. 
Upon receiving a client update, WebFS distributes the 
updates to each of the chat clients connected to it. 
WebFS also accumulates updates, and every 300 ms 
propagates the updates to other servers in the WebFS 
group. This caching model allows for out of order 
message delivery, but wc deemed such semantics to 
be acceptable for a chat application. If it is determined 
that such semantics arc insufficient, well-known dis- 



write (http://serverl/chat, "Hellol"); read(http: //server2/chat , &x) ; 

Chat Server pool 
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read(http://serverl/chat f &x) ; read (http : //server2 /chat , &x) ; 

Figure 7: Implernenlalion of the chat application. Chat rooms are modeled as files with reads corresponding to 
receiving conversation updates and writes to sending out a message. On a write, the WebFS updates all its clients; 
the updates are propagated to other servers in a lazy fashion. 



tribution techniques [Ladin et al. 1 992, Birman 1 993] 
can be used to provide strong ordering of updates. 

Since the read requests are idempotent, and the 
write requests are atomic with respect to WebFS, 
the chat application is completely tolerant to server 
crashes. This fault transparency provides the illusion 
of a single, highly-available chat server machine to 
the programmer of the Chat client interface applet. 
Figure 8 demonstrates the behavior of the chat appli- 
cation in the face of a failure to the client's primary 
server. The graph plots response time as a function of 
elapsed time. The graph shows that chat delivers less 
* than 5 ms latency to the end user. On detecting a fail- 
ure, the latency jumps to I second before switching to 
a secondary WebFS server, at which point the latency 
returns to normal. 

5 Summary 

Wc have described a solution to the problem of scal- 
ability and high-availability which logically migrates 
server functionality into the client. Wc will now re- 
visit the goals set forth in Section I and examine how 
Smart Clients addresses each goal: 

• Incremental Scalability - When a machine is 
added to or removed from a service group, the di- 
rector applet supplied by the service updates its 
list of peer servers. The director applet discov- 
ers such modifications through a service- specific 
mechanism, e.g. keep-alive messages, connect- 
ing to a well-known port, or re fetching the ser- 



vice certificate. 

• Load Balancing - The director applet maintains 
a service-specific notion of load (such as number 
of processes, number of open connections, avail- 
able bandwidth). Using this information, client 
requests are routed to the best candidate node. 

• Fault Transparency - When a failure occurs, the 
director applet allows the client to clean up any 
stale state before rcsending the request to another 
server. Providing fault transparency requires ser- 
vice support when the request is non -idempotent. 
For example, in the chat application, the chat ser- 
vice provides atomic writes to the chat transcript. 

• Wide Area Service Topology - Smart Clients 
does not place any restriction on topology of 
server machines. In fact, the director applet can 
choose an arbitrary site based on considerations 
such as proximity or predicted performance. 

• Scalable Services To Legacy Servers - Existing 
servers that replicate a read-only database can 
be grouped together for access by Smart Clients. 
With knowledge of the group set, the director ap- 
plet can load balance client requests among ex- 
isting unmodified servers. 

Finally, we believe that the architecture presented 
in this paper can simplify implementation of scalable 
services with respect to at least fault transparency and 
load balancing. The Smart Client director provides 
the illusion of a single, highly available server. This 
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Figure 8: Chat response times in the face of server load. The chat application delivers latencies of approximately 
10 ms under normal circumstances. On server failure, the applications takes one second to switch to a peer server. 



model substantially decreases the complexity of the 
client interface applet since this applet need not be 
concerned with maintaining the set of server nodes. In 
addition, because of the public interface between the 
client interface and director applets, each can be writ- 
ten once and interchanged for a number of different 
services. 



6 Related Work 

The problem of transparently providing fault trans- 
parency and load balancing to network services has 
been addressed previously in a number of contexts. 
File systems have used server-side replication of vol- 
umes and servers to provide fault transparency in 
systems such as Deceit [Marzullo ct al. 1990], 
AFS [Howard ct al. 1 988], and HA -NFS [Bhide et al. 
1991]. More recently, systems such as xFS [Ander- 
son et al. 1995b] and Petal [Lee & Thckkath 1996] 
use client-side techniques to improve overall file sys- 
tem performance. Many distributed clusters perform 
load balancing on the level of jobs (interactive or 
otherwise) submitted to the system [Nichols 1987, 
Brickeretal. l991,Douglis&Ouslcrhout 1 99 1, Zhou 
ct al. 1 992]. Once again, all these systems implement 
server-side solutions for load balancing and require 
client intervention to spread jobs among cluster ma- 
chines. 

Perhaps most closely related to Smart Clients are 
Transaction Processing monitors [Gray & Rcutcr 



1993] (TP monitors). TP monitors provide function- 
ality similar to Smart Clients for access to databases. 
The TP monitor functions as the director for transac- 
tions to resource managers^ accounting for load on 
machines, the RPC program number, and any affin- 
ity between client and server. Resource managers 
arc usually SQL databases, but can be any server 
that supports transactions. TP monitors differ from 
Smart Clients in that they deal exclusively with trans- 
actional RPCs as the communication mechanism to 
the servers. TP monitors are also more closely cou- 
pled with the server nodes since they arc responsible 
for starting new server processes. 

The Smart Client director can be tailored to each 
service, while the TP monitor is more of a general pur- 
pose director. Smart Clients also provide a bootstrap- 
ping mechanism to remove the single point of failure 
associated with downloading the necessary routing 
software. In addition, the Smart Client code is signif- 
icantly more lightweight than the TP monitor which 
often includes many of the features of traditional op- 
crating systems: process management/creation, au- 
thentication, and linking resource manager object 
code with the Transaction Processing operating sys- 
tem (TPOS). This lightweight nature enables Smart 
Clients to be downloaded into existing Web browsers 
to customize existing Internet services. 

Also related to our systems are ISIS [Birman 1 993] 
and gossip architectures [Ladin et al. 1992] which 
provide a substrate for developing distributed applica- 



tions. ISIS provides reliable group communication to 
support many of the applications we envision. Gos- 
sip architectures use front-ends analogous to Smart 
Clients to access replicated servers which are kept 
consistent through lazy updates. Both systems are or- 
thogonal to our work in many respects and still use 
server-side techniques for much of their functionality. 

7 Conclusions 

In this paper, we have shown that existing solutions 
to providing transparent access to network services 
suffer from a lack of knowledge about the semantics 
of individual services. The recent advent of Java al- 
lowing distribution of portable client code presents 
an opportunity to migrate certain service functional- 
ity onto the client machine. We show that such mi- 
gration can simplify service implementation and im- 
prove the quality of service to users. To this end, 
we describe our implementation of Smart Clients to 
show the greater flexibility available from a client- 
side approach to building scalable services. The 
Smart Clients API provides a generic interface for ac- 
cessing network services. Further, the decomposition 
of the API into individual client interface and direc- 
tor applets allows interchanging of these applets for 
a variety of services. The Smart Clients API is spe- 
cialized to provide scalable access to three sample ser- 
vices: telnet, FTP, and Internet chat. 

In the future, we will further explore service- 
specific load balancing techniques for achieving scal- 
ability. We also plan to demonstrate how Smart 
Clients can be used to provide load balancing and 
fault transparency for services replicated across the 
wide area. We also plan to implement an interface 
for transparent access to HTTP servers and a fault- 
tolerant telnet client. Migration of other code, be- 
sides the director, from the server to the client will also 
be explored. 
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Abstract. Authentication is a process by which one satisfies another about one's claim of iden- 
tity Typically an authentication server provides the authentication service via an authentication 
protocol The authentication service is a security bottleneck in that its compromise can lead to 
the compromise of the whole system. The service is also a performance bottleneck because many 
activities cannot proceed unless the identities of concerned parties can be satisfactorily established 
Therefore a desirable authentication service should be both highly secure and highly available. We 
propose a general solution by replicating the authentication server such that a minority of malicious 
and colluding servers cannot compromise security or disrupt service. We discuss some unusual fea- 
tures of such a distributed authentication service, including the trade off between availability and 
security 4. distributed service is also useful when clients cannot identify or agree upon trusted 
servers prior to authentication. For example, in some cooperative or federated systems, cheats 
simply cannot all trust the same set of servers. 

1 Introduction 

Authentication is a process by which one satisfies another about one's claim of identity. In mutual 
authentication, pairs of principals, e.g., clients or servers, satisfy themselves mutually about each 
other's identity. Typically an authentication server provides the authentication service via an 
authentication protocol. 

An authentication service is fundamental in maintaining security in a distributed system because 
identification underlines any and all enforcement of any security policy as well as administration 
activities such as accounting and audit. This service is therefore a security bottleneck: once it is 
compromised, no security can be guaranteed. In an open environment, an ...dividual server may 
~TW^r appeared in IEEE Journal oa Selected Ana* .« Co.n.nu.ucal.on,. Vol.11. No i. June. 1903. PP-G37- 
CC2. 
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We organize the rest of the paper as follows. We first recall the concept of authentication and 
describe a typical, centralized, authentication protocol. We then examine the effect of some simple 
replication schemes and demonstrate the trade-off between security and availability. After that, we 
propose a replication scheme and analyze its security properties. We estimate the cost mcurred by 
this replication, as well as possible variations of the basic protocol, and discuss the use of public-key 
cryptosystem. We conclude with a summary and suggestions for future work. 

2 Authentication 

Authentication is by definition a process to verify one's claim of identity. For brevity, we use 
mutual authentication in our discussion, though our results also apply to one way authentication. 
An authentication protocol can be based on either a conventional cryptosystem or a public-key 
system or both (Diffie 76, Needham 78]. We first concentrate on the (most common) case of using 
conventional systems. Later we will discuss the use of public-key systems. Since authentication 
is usually a prelude to further communication and computation, an authentication protocol often 
arranges that the protocol participants, once their identities are verified, agree upon an encryption 
key-a session key-for later use (e.g., within a user session). Thus an authentication protocol is 
sometimes also called a key distribution protocol. 

Let us now examine a protocol that is similar to the Necdham-Schroeder protocol [Needham 78 
Needham 87j, with messages packaged in the style of Otway-Itees [Otway 87|. Client A (or B) 
exclusively shares a secret key Ka (or Kb) with the trusted authentication server S. By executing 
the following protocol, .4 and B intend lo establish a session key Kab. We use A - B : m to 
denote that A sends message m to B. Let {m} k denote m encrypted with key k. and (ml,m2) 
denote concatenation. 

A Typical Centralized Mutual Authentication Protocol. 



1. 


A - 


B : 


A,B,na 


2. 


B — 


5: 


A, 6, na, nb 


3. 


.9- 


B : 


{B, na, Kab}ha, {-4. nb, Ka^Kk 


A. 


B - 


A : 


{B, na, Kab}Ko, {na} Kab, nb 


5. 


A - 


B : 





In message I (or 2), .4 (or B) generates a random number na (or nb) as a challenge, .known as a 
nonce. .S' generates a session kev Kab and distributes it to A and B in message 3. S also encloses 
the nonces in the reply so that A and B can verify that the reply is fresh. Filially, A and B complete 
a handshake to inform each other that the correct session key has been received. 



3 



and communication failure, because they are all availability issues and have the same appearance 
to clients. Also, because bogus messages and faulty messages are not always dist.nguishable, wc 
refer to them simply as illegitimate messages. 

4 Distributed Authentication 

Suppose n servers, S, S n . collectively provide an authentication service.. We assume that a 

client (say A) registers a different key Kai with server <?,, Client .4 can derive these keys from a 
master key Ka. For example, if M) is a suitable one-way hash function (Dime 76, Merkle 90], then 
.4 could register key Kai = h(Ka,Si) with server 5., This arrangement gives extra security since 
one server (say Si) does not know A's other keys (Ka, Ka2, . .., Kan). 

To prevent information leakage, a session key must not.be generated by or known to a single 
server In fact, there is a major difficulty in letting servers involved in choosing the key. Because .4 
and fi do not have a secure communication channel for verification purposes before authenticate 
completes, clients cannot easily reach an agreement on what they have received from which servers. 
Therefore, we let both dients participate in choosing a session key; one may not trust the other s 
competency in this aspect. Although must be capable of generating good random numbers, a client 
concerned about key quality can require a few candidate keys generated by the servers or other 
sources and select one or exclusive-or some of them. The exclusive-or of all candidate keys wiU 
be a good key as long as at least one candidate key is good (presumably chosen by a uncomipto.d 
server) even if some candidate keys are suspect. A preliminary version of the new protocol is as 
follows. 

A Preliminary Distributed Mutual Authentication Protocol. 



1. 


A 


- 5,: 4, B 


2. 


Si 


— .4: nsi 


3. 


A 


B: .4, B, na. nst, (.4. B, nsi,x,}kai 


4. 


B 


5,: .4, B, na. nb, {A, B, nsi, x,)ui, . A, nsi, y,}t6 


5. 


Si 


— B: {B, na, y, ) ka i, { 4. nb, Xi) k bi 


G. 


B 


— A: {B,na,yi)kai, {na}nab,nb 


7. 


A 


- B: {nb) Kah 



Bach participant generates a nonce (nsi for 5„ na for .4. and nb for B), which is later included ... 
encrypted messages (3 though 7) addressed to the participant so that the freshness of the mrs^-s 
can be established [Nccdha.n 87|. With messages I and 2. A obtains a nonce from each serv.M. 
.4 chooses a candidate session key x and computes /,.„(x, i) for each server S,. Here /«,„() is a 
threshold function (Kothari M\ that produces r. shadows of x in such a way that .t .s easy to 
recover x from any / shadows, but less than t shadows reveals no information about x. We will 
explain this function later. In message 3, .4 sends one shadow to each server. In fact, A sends 
to B the shadows which are later forwarded to the servers. Similarly, in message 4, B selects //. 
computes the /, ») s. and sends one shadow to each server. In messages Z and 0, 5, essentially 



The requirement of the additional redundancy is closely related to the concept of verifiable secret 
sharing, which is a scheme for some parties to securely share a secret by keeping different shadows 
yet it is possible to verify that a shadow is legitimate. Some proposed schemes (e.g., (Uior 85J) 
are not very suited to the application here because they use many rounds of messages and usually 
require all participants' cooperation to complete the protocol. We now introduce a cross-checksum 
scheme as a suitable alternative, informally, a cross-checksum scheme supplies checksums together 
with messages in a manner that it is possible to verify the authenticity of the messages by cross 
checking the checksums. We define cross checksums for x and y as cc(i) = (y(*i), - . • ,ff(zn)) and 
cc(y) = (y(y,), • • .,9(y n )), respectively, where g() is a one-way hash function. By replacing x and 
y, with (x„cc(x)) and (y„cc(y)) respectively in the preliminary version of the protocol, we obtain: 

A Distributed Mutual Authentication Protocol. 



1. A - Sr. A, B 

2. Si — A: nsi ^ 

3 .4 — B: A, B, na, nsi, { A, B, nsi, x„ cc(x)}fc„, 

4. S-5.: A,B,na,nb,{A,B,nsi,x i ,cc{x)}ka„{ B <A,nsi,y i ,cc(y)} kbi 

5. S, ; — B: {B,na,y t ,cc(y)} k ai, {A,nb,Xi,cc(x)) k t, t 

6. B — A: {B,na,y i ,cc(y)}kai,{ na )'<*i>< nb 

7. .4 — B: {n6} Ka6 

Adding the cross checksums does not degrade security because g() is a one-way hash function 
(e g [Merkle 901). We require that given a number of pairs z's and y(;)'s. it is computationally 
infeasible to compute k from g(k,x) and x. Moreover, because of the birthday paradox, if g() is 
used in a sufficiently large amount of messages, malicious servers would be able to find x, s thai 
match the cross checksum cc(i) by looking up a dictionary of past messages. To defeat this birthday 
attack, the life time of g() must be hmited according to the properties of the particular funct.on. 
Requirement for h() is similar. In fact, h() and g() can be the same function. 

Since a legitimate message contains legitimate shadows and legitimate cross checksums, and a good 
(i e uncomprised and not faulty) server sends only legitimate messages, A and B can efficiently 
identify legitimate shadows, provided that more than half of the messages received are legitimate^ 
The algorithm is defined as follows. For every g(xj) in cross checksum cc(x) received from .\, it 
Xj is also received from Sj, B recomputes g(xj) from *; and compares it with the received y(x, 
If the two are identical, x, is given one credit point, or rather, 5, gives S t one point. After all 
such checks are done, legitimate shadows are those from the servers which have the highest credit 
points if more than half of the servers are good. To prove this algorithm correct, observe that 
server S, gets a credit point from a good server S, if and only if Sj's shadow is legitimate, Since 
good servers give credits to good servers and they outnumber the bad ones, servers which send 
legitimate messages will receive more credit points. This algorithm computes 0(n ) one-way hash 
functions and comparisons. 

In the protocol, after message 5 (or 6), B (or A) first identifies the legitimate shadows with which to 
recover x (or y), and then computes g{x, y) to obtain the session key. B (or .4 ) considers the service 
u ..available if x (or y) cannot be recovered, i.e., when less than I servers get more than / credit points. 



reliability Hierarchical threshold schemes (Kothari 84] can be used in this case. One scheme is to 
give selected servers more shadows so that they have more say in voting out illegitimate messages 
and they contribute more to availability. This weighted voting approach works well because the 
security parameters (the weights) can be dynamically assigned and a protocol operates consistently 
in the presence of network partitions (Gifford 79|. Moreover, by assigning more votes to some 
servers, clients may communicate with less servers, thus the number of messages ,s reduced and 
the overall availability is improved. This once again demonstrates the trade-off between availably 
and security. 

Servers need not communicate among themselves. Any requirement of coordination among the 
servers for completing the protocol would unnecessarily complicate the situation because more 
messages would be needed and disruptive behavior of compromised servers must be handled prop- 
erly The proposed solution by no means implies that the servers can be placed without adequate 
protection. Only that the compromise or failure of one server is much less of a threat. Conse- 
quently, an authentication server need not necessarily run on adedicated machine and a replicated 
approach may not require additional hardware. 

There are a number of ways to manage the database, e.g., the /etc/passwd file in the Unix system, 
which stores user information including passwords. A server could be regarded as an autonomous 
entity and a user registers and changes keys with each server separately. An alternative is to 
have a trusted master server to maintain a master key database. This server handles initial user 
registration and password change. Periodically it computes from a user's master password his 
passwords for different servers, creates a subsidiary database for each server, and feeds ,t to the 
appropriate server. This master server need hot be on-line or available at all times, thus does not .,, 
general create a performance bottleneck. It need not be a security bottleneck either ,« that it may 
discard the master passwords once the subsidiary databases are installed. In this case, a user could 
set up a secure channel with the master server by using the distributed authentication service. 

Sometimes, some participants of the protocol are capable of remembering long secrets and have 
the computational capability to use public-key cryptosystems. One such case is when .4 is a user 
equipped with a smart-card and B is a file server. In such cases, the distributed authentication ser- 
vice can take advantage of the special features of public-key cryptosystem to improve the efficiency 
of the authentication protocol. 

Suppose that A and B have public keys K„ and respectively, and they keep the corresponding 
private keys secret. Also assume that they still share conventional system keys with the servers. 
Now an authentication protocol could arrange that .4 obtains (instead of y) and /? obtains h,, a 
(instead of x) [Necdham 78], similarly using the servers as brokers. Since R pa (or A pt need not be 
kept secret, the only requirement is that B (or .4) should not, perhaps as a result of cheating on 
the part of some servers, associate a different public key with .4 (or B). Thus we no longer need 
the secret-sharing scheme, nor the cross-checksum scheme, and the protocol can be amplified by 
replacing (x„cc(x)) with K pa , and (y..cc(y)) with /v pt in the messages. After rece v ng messages 
from the servers, .4 (or B) performs a (possibly weighted) voting on Bs (or 4 s) public keys 
received. If no majority is found, A (or B) considers the service unavailable. Otherw.se, they can 
use the two keys directly for subsequent communication, or they can arrange a further session key 
(for a conventional crvptosvstem) [Needham 78). The handshake messages need to be modified 
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Java is an object-oriented programming 
language that was created by Sun. 
Microsystems in 1991 for use in consumer 
goods like VCRs In the mid-1990's Java t 
became a popular programming language for 
the World Wide Web, and it has increased in 
popularity sine e. Java's popularity for Web 
applications has, in large part, been a result of 
the popularity of Netscape. (The Netscape 
Navigator browser has supported Java since 
release 2.0. ) 

Recently, Java has been in the news because 
its developers, Sun Microsystems, have 
tussled with the Microsoft Corporation over 
Microsoft's licensing agreement with Sun. 
Microsoft has not included important Java 
development material in its developer's ki t for 
Internet Explorer 4.0. (Jones) At the heart of 
the conflict is Java's identity: is Java a 
language or is Java a platform? Sun says Java 
is a platform -the company has 3,000 Java- 
based network computers at their company. 
Microsoft has countered b y saying that Java 
is just a language. (Engst) Another sticking 
point is Microsoft's reluctance to support the 
"100% Pure Java" endeavor by Sun. Java's 
official slogan "Write once, run anywhere" is 
indictative of the language's portabilty. It is a 
lang uage than can used for any programming 
application, not just Web programming, and it 
can be used on any computing platform. 
Microsoft, a company that has sold the most 
Java development tools, offers development 
tools that allow programmers to write Wind 
ows-specific Java, and that impinges upon the 
portability of Java. And there's the rub. And 
the lawsuit. (Wired) 

Most of the time, when a computer program is 
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Javascript began as an attempt by Netscape 
Communications to integrate the functionality 
of Sun Microsystems' Java programming 
language with HTML for WWW applications. 
The hope was that this new language, which 
would be a "scripting language," would be 
simpler to understand than Java and would 
provide web designers with the ability to 
Include interactive elements in their pages 
without having to master a complex 
programming language. The initial attempt 
yielded a scripting language known as 
"LiveScript." Recognizing the value of this 
project, Sun joined forces with Netscape, and 
"LiveScript" became "JavaScript." 

HTML is the markup language used for Web- 
based documents. It allows a designer to 
create a static environment for her content. If 
the designer wants to include dynamic 
elements in her page, she must turn to a 
scripting language such as JavaScript, an i 
nterface like CGI that utilizes a scripting 
language such as Perl, or a programming 
language such as Java or C, to accomplish 
this. CGI is the most commonly used interface 
that allows scripting on the Web, and 
designers use it to include interactive elements 
such as forms and search engines in their Web 
pages. However, CGI is "server-side." This 
means that the program runs on the server that 
it resides on, rather than on the usei's machine 
(client side). If a connection is slow, or the 
server is'overtaxed or otherwise limited, a . 
server-side application may be relatively sIqvy, 
and may take a long time to run. JavaScript is 
a "c lient-side" process, similar to Java. It 
loads and runs on the user's machine, and does 
not require calls back and forth to the server 
for its implementation. This gives it the 
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translated into machine code ("compiled") so 
a computer can understand it, the resulting 
machine code can only be understood by other 
computers of the same system type. Java, 
however, is different. When a Jav a program is 
compiled, it can be run on various platforms 
(it is "portable"). This portability, and the fact 
that Java applets are small and speedy, make 
Java an ideal programming language for the 
Web. The Web itself is platform independent. 
(Javasc ript takes this further-a Javascript 
applet does not need to be compiled. This is 
one of the biggest differences between Java 
and Javascript.) 

Java is easier to leam than C++, the language 
it was modeled upon. For experienced 
programmers, it is quite simple. Novice Java 
programmers, on the other hand, first have to 
understand the basics of object oriented 
programming. 

Small Java programs ("applets") can be 
inserted into HTML documents using the 
SGML-compliant <APPLET> tag. Java 
enables static HTML documents to become 
interactive, by adding features like forms, by 
manipulating user input, and by helping to 
automate Web design and maintainance. 

Java 1.0 is supported by: Netscape Navigator 
for Windows 2.0 and above; Netscape 
Navigator for Macs 3 .0 and above; Internet 
Explorer 3 .0 and above; and Sun's HoUava. 

Only one browser fully supports Java 1.1: 
Sun's HoUava. Netscape's Navigator 
Communicator and and Microsoft's Internet 
Explorer 4.0 only support portions of Java 1.1. 
(Harold) 

References: 

DevEdge Champion 

Netsca pe DevEd ge News group Fr equently, 

Mk^..Ques.aon§: iasa 

Engst, Adam C. 
Reading the Co ffee Grounds 
In MacWeek Online December 3, 1997 

Harold, Elliotte Rusty 



potential to produce faster results than a 
server-side application. 

A scripting language is a language that 
consists of "a sequence of program 
instructions (called statements)." (Idiot, 12) 
This is programming, but scripts are simpler 
to learn and set up than programming 
languages. JavaScript, like Java, is object- 
oriented. This simply means that when a 
person is writing a JavaScript, she is 
concentrating on the various pieces, or 
objects, that she needs to work with in her 
program. 



A web page consists of many different objects 
that can be affected with a JavaScript. There 
can even be objects within objects. For 
instance, the HTML document that generates 
the web page is an object, and each sub- 
section of that document can also be an object: 
a text box, a radio button, a form. The browser 
window itself is an object, as is the status bar 
of the browser, etc. "The basis for the concept 
of object-oriented programming [is that] the 
programmer is more concerned with what an 
object is doing than how it gets done." (Idiot, 
13) However, JavaScript has objects built-in 
that provide the designer/programmer with the 
functionality she needs New objects can't be 
created, like they can in Java, so the 
designer/programmer doesn't have to worry 
about originali ty. 



The main problem with JavaScript, currently, 
is its portability. It can only be fully 
implemented on Netscape's browser, and only 
version 3 or greater. It tends to crash earlier 
versions of this browser. Microsoft's Internet 
Explorer implements ActiveX, a competitive 
technology, but does not recognize JavaScript. 
To avoid browser conflict, designers should 
create a site that will allow users with 
different browsers to access different pages 
according to their browser's ability to view 
JavaScript. Netscape's online magazine, 
"View 

Source" (http://developer.netscape.com/news/viewso 
urce/), offers advice on setting up a 
mechanism on a web page that will detect a 
user's browser and route that user to an 
appropriate page (see Detecting a JavaScrip t 
Client by Danny Goodman). Designers should 
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also include <ALT= ,,M > tags in their HTML 
code whenever JavaScript is called to provide 
an alternative to the JavaScript function. 

JavaScript is easily integrated into the HTML 
code for a web page. The script resides in the 
header information, and is "commented" off 
so non-JavaScript browsers cannot view (or 
recognize) the code. Function calls that refer 
back to the script are plac ed within the main 
HTML code of the web page. Unlike Java or 
CGI, JavaScript does not require a separate 
file for code, although the designer has the 
option of placing her code in a separate file. 
Again, JavaScript is an attempt to put the 
capability for creating interactive, dynamic 
web pages into the ha nds of the non- 
programmer. 

References: 
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Major Differences 



Java 



JavaScript 



Can be used for various programming 
purposes. 

Is a compiled language. 

Code is compiled into Applets (separate 

from HTML) 

Is a programming language. 



• Is used for Web programming only. 

• Is not a compiled language. 

• Code is embedded directly in HTML. 

• Is a scripting language. 



Back to Main Java vs JavaSc ript Page 
http://www.it.utk.edu/itc/clearinghouse/java/jvsjs.html 
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Subject: Re: AOL0091 draft comments needed [ks 
Date: Wed, 14 May 2003 16:42:15 -0700 ||g 
From: Rhonda P»nn <rhonda® glenn-law,com> 

To: A PI COOT Cqhj ll <^orariill@ao| T fflm> 

CC: pon Hendvicfa <flQPto^i g n® cartMpfcin^ 
References: 1 



Hi Conor, 

Attached is the draft patent application and draft drawings for AOL0091 " IDENTITY 
BASED SERVICE SYSTEM" . At this time you are the only inventor we aware of . I need 
to know if Andy Feng, Aleksey Sanin, Chris Toomey and Rob Weltman are also 
inventors. Any one else? 



Please let me know asap so I can get the drafts out for review. 
Thanks so much. 



Rhonda 

Patent Administrator 



Glenn Patent Group 
3475 Edison Way, Suite L 
Menlo Park, CA 94025 
650-474-8400 (Tel) 
650-474-8401 (Fax) 



This message is intended only for the individual to whom it is addressed and may 
contain information that is confidential, privileged, or otherwise exempt from 
disclosure under applicable law. If you are not the individual to wham this message 
is addressed, you are advised that any use, copying, or disclosure of this message 
or the contents thereof is without permission and contrary to law. If you receive 
this message in error, please call 650-474-8400. 




Name: AOL009l.App.Vl 4.15.03.doc 
Type: Microsoft Word Document (application/msword) 
Encoding: base64 
Description: Unknown Document 
Download Status: Not downloaded with message 




Name: Dwgs 5.13.03.vl.pdf 
Type: Portable Document Format (applicauon/pdf) 
Encoding: base64 
Description: Unknown Document 
Download Status: Not downloaded with message 
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Conor Cahill 
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3175 

f engandyfcaol . cam 



1 703 265 
1 650 937 



4813 



Aleksey Sanin 1 650 937 6751 



ConCahilieaol . cam 



aleksey@aol.net 



Chris Toomey 1 650 937 4508 
CToomeyGaol . com 



Rob Weltman 



650 937 3194 



rweltmanOnetscape . com 



Tammy Davis <tdavis @netscape.corn> 
Lead Rec eptionist 
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Re: AO 10091 draft 



Subject: Re: AOL0091 draft comments needed 
Date: Thu p 15 May 2003 07:31:22 -0400 
From: "Conor P. Tahiti" <concahil1@aoi.com> 
Organization: America Online, Inc. 

To: "Rhonda Dunn" <monda@g}enn-1aw.com> 

CC: "Pon rfcrifrjciq" <dcmliteigp^c9nhtfnH f nct> 
References: 1 , 2 

I know... It's on my list of things to do, just haven't gotten the time 
to do so. 

Chris Toomey, David Wexelblat, Jim Roskind, Edwin Aoki, and Jeromy 
Carriere and possibly Andy Feng (I'm not sure when he got involved in 
the project) . 

Conor 

Rhonda Dunn wrote: 

> Hi Conor, 
> 

> Attached is the draft patent application and draft drawings for 

> AOL0091 "IDENTITY 

> BASED SERVICE SYSTEM". At this time you are the only inventor we aware 

> of. I need 

> to know if Andy Feng, Aleksey Sanin, Chris Toomey and Rob Weltman are 

> also 

> inventors. Any one else? 
> 

> Please let me know asap so I can get the drafts out for review. 
> 

> Thanks so much. 
> 

> Rhonda 
> 

> Patent Administrator 
> 

> Glenn Patent Group 

> 3475 Edison Way, Suite L 

> Wen Jo Park, CA 94025 

> 650-474-8400 (Tel) 

> 650-474-8401 (Fax) 
> 

> This message is intended only for the individual to whom it is 

> addressed and may 

> contain information that is confidential, privileged, or otherwise 

> exempt from 

> disclosure under applicable law. If you are not the individual to 

> whom this message 

> is addressed, you are advised that any use, copying, or disclosure of 

> this message 

> or the contents thereof is without permission and contrary to law. If 

> you receive 

> this message in error, please call 650-474-8400. 
> 

> AOL0091.App.Vl 4.15.03.doc Dwgs 5.13.03.vl.pdf 
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Rk AOL0091 etotl o 



Subject: Re: AOL0091 draft comments needed 
Date:Thu, 15 May 2003 13:21:19-0400 
From: "Conor P. Cahill" <concahil1@aol«)m> 
Organization: America Online, Inc. 

Tn: ''Rhonda Dunn" <rhonda@glenn-law.com> 

CC: "Don Hendricks" <donnteign@garrhlinX-nct> 
References: 1,2,3,4 



Rhonda Dunn wrote: 

> Hi Conor - 
> 

> I'd like to send the draft out for everyone to review. As I recall 

> from my 

> days at Netscape/AOL, Edwin and Jeromy are no longer with the company. Do 

> you have email addresses for them? Do you have an email address for 

> David? 
> 

Edwin is still here (EdwinAoki@aol.net). 

Jeromy has left but can be reached at: J@TheCarrieres.com. 
David can be reached at: DavidWexelblat@aol .cam 



Conor 
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Subjecb^COL0091 draft comments needed IjSjEI 
~ : Thu t 22^4^2003 17:5a.28 -0700 USD 
^■^hDrnfiTDiinn <rhonda@glenn-law.com> _„ . 

To: "Conor P. Cahill" <concahin@aol.com> . Edwin Aoki <edwinaoki@aol.nct>. Jereomy Camas <JCT?rt^ere$xQrn>, 

David Wexclbla t <DavidWexelblai@aol.com> 
CCi Don Hendricks <donhdesiim(a>carthlink.nct> 
References: 1,2,3,4,5 

Hi Conor, Edwin, Jereomy and David, 

Attached is the draft of your patent invention "IDENTITY BASED SERVICE SYSTEM" and the drawings. Please review both documents and send your comments to 
Don - please redline or track changes, or email your comments directly to him 

Please respond with approval or changes by June 2. Let me know if you have any problems opening the draft or drawings. 

Thanks, 

Rhonda 



Rhonda Dunn 
Patent Administrator 

Glenn Patent Group 
3475 Edison Way, Suite L 
Menlo Park, CA 94025 
650-474-8400 (Tel) 
650-474-8401 (Fax) 
Rlionda@glenn-law.com 

Tlits message Is intended only for the individual to whom it is addressed and may contain information thai is confidential, privileged, or otherwise exempt from disclosure under applicable law. Jf you are not 
the individual to whom this message is addressed, you are advised thai any use, copying, or disclosure of this message or the contents thereof is without permission and contrary to law. If you receive this 
message in error, please call 650-474-8400. 





Name: AOL0091 App.Vl 4.15.03.doc 
Type: Microsoft Word Document (application/msword) 
Encoding: base64 




Description: Unknown Document 
Download Status: Not downloaded with message 





Name: AOL0091.Dwgs.vl.pdf 




Type: Portable Document Format (apphcation/pdf) 




Encoding: base 64 




Description: Unknown Document 




Download Status: Not downloaded with message 
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Thwmtay. Juw 19. 2008 AOlOOflt draft wvtow, 2nd »<*i««< 

Subject: AOL0091 draft review, 2nd request 
Date: Wed, 11 Jun 2003 13:54:31 -0700 

From: RfrQnflq Pwm <rtQnda<agknn-law,CQrrp> a/ ^ t ^ tjtii ili ^ ijw „ , ^ , 

To: AOL Conor Cahill <concahill@aot.com> . Edwin Aoki <edwinaoki@ao1.net> . AQL David We*elblat <pav)dW^elM^@aQl.com>, 

Jereomv Carriere <J@TheCameres.com>. Jeromv <sicarriere®hoiroail.corn> 
CC: AOL Reports <PatRpl2O030507@ao1.comx Pon ffcpdricks <riPnMreign@raT^lmKnet> 

Hi Jerorrry, David, Conor and Edwin, 

We are waiting for your comments. Please review the draft and drawings 
and send your comments to Don Hendricks by Friday, June 13. 

I need your home mailing address and citizenship information for the 
filing forms. Please reply as soon as possible. 

Thanks so much, 

Rhonda , 



Subject: AOL0091 draft comments needed 
Date: Thu, 22 May 2003 17:50:28 -0700 
From: Rhonda Dunn <rnQnda@g)epn4a\Y-C^rri> 

To: "Conor p. Cahill" ^oncahill^aQi.com^ Edwin AoKi <^wiwQki@aol.net>, Jergomy Carriers <JffTfotam (res.com>, 

pavid Wexelfriat <DavidWexeiMaK?aolfflirc> 
CC: Ppn Hendrick s <dpnhriegjgn®eaithlinkjiet> 
References: 1,2,3,4,5 

Hi Conor, Edwin, Jereomy and David, 

Attached is the draft of your patent invention "IDENTITY BASED SERVICE SYSTEM" and the drawings. Please review both documents and send your comments to Don - 
please redline or track changes, or email your comments directly to him 

Please respond with approval or changes by June 2. Let me know if you have any problems opening the draft or drawings. 

Thanks, 

Rhonda 



Rhonda Dunn 
Patent Administrator 

Glenn Patent Group 
3475 Edison Way, Suite L 
MentoParic, CA 94025 
650-474-8400 (Tel) 
650-474-8401 (Fax) 
Rhonda@glenu-law.com 

This message is intended only for the individual to whom it is addressed and may contain information that is confidential, privileged, or otherwise exempt from disclosure under applicable law. If you axe not the 
uidividual to whom this message is addressed, you are advised that any use, copying, or disclosure of this message or the contents thereof is without permission and contrary to law. If you receive this message in 
error, please call 650-474-8400 



^AQLQWl.Aro-V14.l5,03,<lPC 



Name: AOL009l.App.Vl 4.15.03.doc 
Type: Microsoft Word Document (application/msword) 
Encoding: base64 
Description: Unknown Document 
Download Status: Not downloaded with message 



Name: AOL0091.Dwgs.vl.pdf 
Type: Portable Document Format (applicatiorj/pdf) 
Encoding: base64 
Description: Unknown Document 
Download Status: Not downloaded with message 
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Thursday, July 17, 2003 



Re: AOL0091 Patent Draft •Comments due ASAP! 



Page: 1 



Subject: Re: AOL0091 Patent Draft ^Comments due ASAP! 
Date: Thu, 17 Jul 2003 13:53:06 -0400 
From: "David Wexelblat" <davidwexelblat@aol.com> 
Organization: America Online, Inc 

To: "Jessica Pallach" <jessica@glenn-law.com> 

CC: "Conor Cahiir <ConCahill@aol.comx edwinaoki@aol.net , j@thecarrieres.com . 
sjcarriere @ hotmai 1 .com 
References: 1 



Jessica Pallach wrote: 

Hi Conor, Edwin, David, and Jeromy, 

Further to our emails of May 22 and June 11, we are still awaiting your review comments and/or approval to file the 
above-referenced application. I've attached another copy of the application and figures for your convenience. 

Please make your final review (if you have not yet done so) and email your red-lined version, or approval to file, to 
me by Friday, July 18 T 

've been working on a firedrill for the last couple of months which isn't going to let up until at least the end of the 
month, so I haven't been able to do a detailed line-by-line review. I will try to send some more comments if I can, but the 
one big issue I have is that "core services" is defined as authentication, profile, wallet calendar and alerts. I think this is 
an overly-broad definition, one that would be susceptible to being implemented around (e.g. someone implements what 
we've described, but without calendar, it isn't the service as we've described). For what we are trying to define here, 
only authentication, and possibly profile, would be considered "core" and everything else applications on top of these 
core services. With the definition of "core authentication record" and "discovery service", I don't think profile is even 
core. 

I think the ambiguity arose from the set of services initially planned for Magic Carpet Network V1. Those services were 
core to business, not core to the technology or implementation thereof. 

Please also send me your full name, residence address, and country of citizenship. I need to prepare the formal 
documents and will email them to you for signatures 

David Eli Wexelblat 
1811 Vance Place 
Vienna, VA 22182 
Citizen of USA 

Please let me know if you have any questions. I look forward to hearing from you soon. 
Thanks! 

Jessica L. Pallach 

Patent Administrator / IP Database Manager 

Glenn Patent Group 
3475 Edison Way, Suite L 
Menlo Park, CA 94025 
650-474-8400 
650-474-8401 (Fax) 
je$$ic3@qlenn-tew,CQm 



This message is intended only for the individual to whom it is addressed and may contain information that is 
confidential, privileged, or otherwise exempt from disclosure under applicable law. If you are not the individual to 
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Tuesday, July 22, 2003 



Re: AOL0091 Patent Draft •Comments due ASAP! 




,1 p j6 V\U/VM*t$ S 



Subject: Re: AOL0091 Patent Draft *Comments due ASAP! 
Date: Mon, 21 Jul 2003 07:54:27 -0700 
From: Edwin Aoki <edwinaoki@aoLnet> 

To: Jessica Pallach <jessic a@glenn-law.com> . 
CC: Conor Cahill <ConCahill @aol.com>. davidwexelblat@aol.com. j@thecarrieres.com, NON 
sjcarriere@hotmail.com ^ 
References: 1 

Jessica, 





I apologize for the delay; I was out of town for the past three weeks 
and am just now getting through the backlog of email. (Of course, I do 
recognize that I've had this draft for longer than that) . I've included 
redlines in the attached document. Some are clarifications (as 
requested) and others are some corrections to figure numbers based on my 
reading of the text. I would appreciate it if yu could attempt to 
verify that I interpreted the text correctly in making the corrections; \*\<->f2-iS 
this is not simple stuff, and it's been a while since we'd looked at s 
some of this system design. 



Thanks again for your effort to make this understandable 
understandable to the folks over at the PTO. :-) 



or at least 



Let me know if you have 
-Edwin 



any further questions, 



y 



P.S. The information you asked for: 



Norihiro Edwin Aoki 

1296 Morningside Drive, Sunnyale, CA 94087-1555 
Citizen of the United States. 



Jessica Pallach wrote: 

> Hi Conor, Edwin, David, and Jeromy, 
> 

> Further to our emails of May 22 and June 11, we are still awaiting 

> your review comments and/or approval to file the above-referenced 

> application. I've attached another copy of the application and figures 

> for your convenience. 
> 

> Please make your final review (if you have not yet done so) and email 

> your red-lined version, or approval to file, to me by *_Friday, July 

> 18. _* 
> 

> Please also send me your full name, residence address, and country of 

> citizenship. I need to prepare the formal documents and will email 

> them to you for signatures 
> 

> Please let me know if you have any questions. I look forward to 

> hearing from you soon. 
> 

> Thanks! 

> — 

> Jessica L. Pallach 

> Patent Administrator / IP Database Manager 
> 

> Glenn Patent Group 

> 3475 Edison Way, Suite L 

> Menlo Park, CA 94025 

> 650-474-8400 

IMAP7/1 92.168. 1.2?fetch>UID>/INBOX>1009 



Attorney Docket No. AOL0091 

IDENTITY BASED SERVICE SYSTEM 



FIELD OF THE INVENTION 

5 

The invention relates to the field of network based services and structures. More 
particularly, the invention relates to identity creation, management, authentication, and 
authorization structures for enhanced network services. 

10 BACKGROUND OF THE INVENTION 

At the present time, the identity of an individual or user in a network environment, such 
as the Internet, is comprised of a large number of pieces of information, which is 
collected and recollected by a large number of entities. Some basic information 

15 regarding an individual, such as but not limited to name information, address 
information, identification information, financial information, profile information, and or 
preference information, is repeatedly collected and stored at a large number of system 
entities. Additional information, such as a user name and password, is created, as 
necessary, such that the individual or user can sign on and/or gain access to a service 

20 provider. 

A large number of pieces of an individual's business and personal identity are therefore 
scattered across an increasing number of system entities, such as but not limited to 
commercial entities, banking and investment institutions, credit card companies, service 
25 providers, and/or educational institutions. 

Individuals are therefore required to repeatedly enter much of the same information, in 
the process of numerous professional and/or personal endeavors. Furthermore, as the 
information for an individual changes, the stored information becomes increasingly 
30 impractical to manage and/or update. In addition, the numerous user names and 
passwords associated with an individual quickly becomes unwieldy, such that users 

1 



Attorney Docket No. AOL0091 PROPRIETARY INFORMATION - REVIEW DRAFT 15 April 

2003 

often forget or lose track of the information they need to access services and/or 
accounts. 

Several structures and methods have been described for identity and proxy-based 
5 networks, such as: 

E. Gabber, P. Gibbons, Y. Matias, and A. Mayer, System and Method for Providing 
Anonymous Personalized Browsing by a Proxy System in a Network, U.S. Pat. No. 
5,961,593, 05 October 1999, describes a system "For use with a network having server 

10 sites capable of being browsed by users based on identifiers received into the server 
sites and personal to the users, alternative proxy systems for providing substitute 
identifiers to the server sites that allow the users to browse the server sites 
anonymously via the proxy system. A central proxy system includes computer- 
executable routines that process site-specific substitute identifiers constructed from 

15 data specific to the users, that transmits the substitute identifiers to the server sites, that 
retransmits browsing commands received from the users to the server sites, and that 
removes portions of the browsing commands that would identify the users to the server 
sites. The foregoing functionality is performed consistently by the central proxy system 
during subsequent visits to a given server site as the same site specific substitute 

20 identifiers are reused. Consistent use of the site specific substitute identifiers enables 
the server site to recognize a returning user and, possibly, provide personalized 
service"; 

Proxy-Based Security Protocols in Networked Mobile Devices] M. Burnside, D. Clarke, 
25 T. Mills, S. Devadas, and R. Rivest; MIT Laboratory for Computer Science; 
event,declarke,mills,devada, rivest@mit.edu; 

SPKI/SDSI http Server / Certificate Chain Discovery in SPKI/SDDI] D. Clarke; MIT 
Laboratory for Electrical Engineering and Computer Science, September 2001 ; 

30 
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Grid Information Services for Distributed Resource Sharing; K. Czajkowski, S. 
Fitzgerald, I. Foster, C. Kesselman; Proc. 10 th IEEE Symposium on High-Performance 
Distributed Computing, 2001; 

5 Certificate Discovery Using SPKI/SDSI 2.0 Certificates; J. Elien; MIT Department of 
Electrical Engineering and Computer Science; May 1998; and 

Local Names in SPKI/SDSI; N. Li; NYU Department of Computer Science; Proceedings 
of the 13 th IEEE Computer Security Foundations Workshop. 

10 

Other systems provide various details of the operation of network identity and proxy 
systems, such as U.S. Patent No. 6,460,036, System and Method for Providing 
Customized Electronic Newspapers and Target Advertisements; U.S. Patent No. 
6,029,195, System for Customized Electronic Identification of Desirable Objects; U.S. 

15 Patent No. 5,835,087, System for Generation of Object Profiles for a System for 
Customized Electronic Identification of Desirable Objects; U.S. Patent No. 5,754,939, 
System for Generation of User Profiles for a System for Customized Electronic 
Identification of Desirable Objects; U.S. Patent No. 5,754,938, Pseudonymous Server 
for System for Customized Electronic Identification of Desirable Objects; U.S. Patent 

20 No. 6,490,620, Integrated Proxy Interface for Web Based Alarm Management Tools; 
U.S. Patent No. 6,480,885, Dynamically Matching Users for Group Communications 
Based on a Threshold Degree of Matching of Sender and Recipient Predetermined 
Acceptance Criteria; U.S. Patent No. 6,473,407, Integrated Proxy Interface for Web 
Based Alarm management Tools; U.S. Patent No. 6,421,733, System for Dynamically 

25 Transcoding Data Transmitted Between Computers; U.S. Patent No. 6,385,652, 
Customer Access Solutions Architecture; U.S. Patent No. 6,373,817, Chase Me 
System; U.S. Patent No. 6,338,064, Method for Enabling a Web Server Running a 
"Closed" Native Operating System to Impersonate a User of a Web Client to Obtain a 
Protected File; U.S. Patent No. 6,259,782, One-Number Communications System and 

30 Service Integrating WirelineAA/ireless Telephone Communications Systems; U.S. Patent 
No. 5,974,566, Method and Apparatus for Providing Persistent Fault-Tolerant Proxy 
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Login to a Web-Based Distributed File Service] European Pat. No. EP 1094404, 
Collaborator Discovery Method and System] European Pat. No. EP 1031206, Identity 
Discovery method for Detecting Authorized Security Service Which is Illicitly 
Transferring Decoding Capabilities for use in Unauthorized Security Devices] The 
5 Session Initiation Protocol: Internet-Centric Signaling; H. Schulzrinne, J. Rosenberg; 
IEEE Communications Magazine; October 2000; How Bluetooth Embeds in the 
Environment] Lawday, G.; Electronic Product Design; Nov. 2001; and Business: 
Designing with Users in Internet Time; J. Braiterman, S. Verhage, and R. Choo; 
Interactions: Sept.-Oct. 2000. 

10 

It would be advantageous to provide an identity based service system, which does not 
require a user to create a user identity for each service provider. The development of 
such an identity based service system would constitute a major technological advance. 

is Furthermore, it would be advantageous to provide a identity based service system, 
which allows a user to create a an identity which can be controllably accessed and 
shared by a plurality of service providers. The development of such an identity based 
service system would constitute a further technological advance. 

20 As well, it would be advantageous that such an identity based service system be 
integrated with existing site authentication and authorization structures, such that the 
identity based service system is readily used by a wide variety of sites. The 
development of such an identity based service system would constitute a further major 
technological advance. 

25 

SUMMARY OF THE INVENTION 

An identity based service system is provided, in which an identity is created and 
managed for a user or principal, such that at least a portion of the identity is available to 
30 use between one or more system entities. A discovery service enables a system entity 
to discover a service descriptor, given a service name and a name identifier of the user, 
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whereby system entities can find and invoke the user's other personal web services. 
The discovery service preferably provides a translation between a plurality of 
namespaces, to prevent linkable identity information over time between system entities. 

5 BRIEF DESCRIPTION OF THE DRA WINGS 

Figure 1 is a basic functional block diagram for an identity based service system, in 
which a service provider accesses services for a principal; 

10 Figure 2 is a flow diagram for the access of service within an identity based service 
system; 

Figure 3 is a functional block diagram of an identity based service system, comprising a 
discovery service associated with an identity provider, a web service provider, and a 
15 web service consumer; 

Figure 4 is a flow diagram for the access of service within an identity based service 
system comprising a discovery service associated with an identity provider, a web 
service provider, and a web service consumer; 

20 

Figure 5 is a functional block diagram of an identity based service system, in which a 
discovery service issues service assertions that are used to invoke services; 

Figure 6 is a flow diagram for the access of service in the identity based service system 
25 shown in Figure 5; 

Figure 7 is a functional block diagram of profile service principal core information; 

Figure 8 is a functional block diagram of a profile data entry; 

30 
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Figure 9 is a schematic view of an identity based service system configured on a virtual 
network; 

Figure 10 is a functional block diagram of a core authentication record; 

5 

Figure 1 1 is a functional block diagram of multiple core authentication records which are 
maintained on behalf of a plurality of identities for a user; 

Figure 12 is a functional block diagram of multiple core authentication records 
10 maintained on behalf of a user, based upon system access through different devices; 

Figure 13 is a schematic view of namespace translation within the identity based 
service system; 

15 Figure 14 is a first schematic view of operation for an identity based service system, in 
which user logs onto a first service provider site; 

Figure 15 is a second view of operation for an identity based service system, wherein a 
users may select system site links and/or system service links; and 

20 

Figure 16 is a third view of operation for an identity based service system, in which a 
system identity is established at an identity provider. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

25 

Figure 1 is a basic functional block diagram for an identity based service system 10a, in 
which a service provider 16 accesses services for a principal 12. Figure 2 is a flow 
diagram 30 for the access of service within an identity based service system 10. In 
Figure 1, the system entities 27 comprise an identity provider 14, a service provider 16, 
30 and a principal 12. The system entities 27 assume roles within the identity based 
service system 1 0. 
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A principal 12, such as a user or user agent, is an entity 27 that can acquire a system 
identity 29, and be authenticated and vouched for 19 by an identity provider 14.' A 
principal 12 often comprises a user, using a user agent, either a web browser or a 
5 smart web services client. 

An identity provider (IDP) 14 authenticates and vouches for principals 12, and provides 
system management for system identities 29. A service provider (SP) 16 provides 
service to one or more requestors, such as principals 12, typically through a web 
10 consumer 48 (Fig. 3), upon proof of authentication 19 by the identity provider 14. 

The identity based service system 10a shown in Figure 1 provides a web services- 
based service infrastructure that enables users U to manage the sharing of their 
personal information across an identity provider 14 and service providers 16. In some 
15 system embodiments 10, the system 10 also provides personalized services 116 (FIG. 
9) for users U (FIG. 11). 

For example, a user U, through a principal 12, is able to authorize a service provider 16 
to access his or her contact data 94a (FIG. 7), such as shipping address data 96 (FIG. 

20 7), while processing a transaction. Principals 12 are able to use sophisticated clients 
that support web services, in addition to traditional browser-oriented user agents. In 
some system embodiments, web services are defined as simple object access protocol 
binding (SOAP) over http calls, comprising header blocks and processing rules, which 
enable the system to invocation identity services 116, through SOAP requests and 

25 responses. 

The identity based system framework 10 enables service providers 16 and other 
system entities 27 to craft and offer sophisticated services, including multi-provider- 
based services 116 (FIG. 9). 



7 



Attorney Docket No. AOL0091 PROPRIETARY INFORMATION - REVIEW DRAFT 15 April 

2003 

' Figure 3 is a functional block diagram 40 of an identity based service system 10b, which 
further comprises a discovery service 42 associated with the identity provider 14, a web 
service provider 42, and a web service consumer 48. Figure 4 is a flow diagram 60 for 
the access of service within an identity based service system 10b. 

5 

A web service provider (WSP) 54 hosts personal web services 116 (FIG. 9), such as a 
profile service 116b (FIG. 9), while a web service consumer (WSC) 48 invokes web 
services 116 at web service providers WSP 54. With appropriate identification and 
authorization, a web service consumer 48 is able to access the user's personal web 
10 services 1 16, by communicating with the web service provider endpoint 54. 

As seen in Figure 3, the identity provider IDP 14 provides authentication 19 to the 
principal 12, based upon a successful log in 18. The principal 12 then interacts with the 
service provider 16, and relays the authentication information 19, comprising an IDP 
is assertion 45 and a discovery service descriptor 26. 

The service provider SP 16, acting as a web service consumer 48, uses the discovery 
service 42, to determine whether the principal 14 is enabled for a particular service 116, 
and to obtain the necessary assertions which authorize use of the service 116. The 
20 policy framework addresses whether the principal 12 is enabled for some particular 
service, and if so, what fine-grained methods are allowed, and what data is to be 
returned. Web service security is typically applied to all messages flowing between 
system entities 27. 

25 As seen in Figure 3, the identity based service system 10b comprises a web-service 
infrastructure, which comprises the discovery service 42, service invocation 52, a 
permission and authorization framework, a change management framework, as well as 
a mobile infrastructure. 
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In some system embodiments 10, web service consumers 48 are hosted on a server at 
a service provider 54. In alternate system embodiments 10, web service consumers 48 
are hosted on a user device 192 (FIG. 14). 

5 A discovery device (DS) 44 is typically hosted by an identity provider (IDP) 14, and 
enables web service consumers 48 to discover service endpoint information 96 (FIG. 7) 
associated with the personal web services 1 16 of a user U. 

Architectural Components. The identity based service system 10 comprises the 
10 following architectural components: 

Services. A service is a grouping of common functionality. For example, a core 
profile service 116b (FIG. 9) handles all interaction to do with user profile 
information 96. Services typically offer one or more methods callers use to 
15 manipulate the information managed by the service, and are typically scoped in 

the context of a particular principal 12, e.g. GetProfile (Principal) accesses the 
principal's entire set of profile data. 

Services may be either RPC-style or one-way exchanges. In RPC-based 
20 exchanges, the Web Services Consumer 48 is the requestor 50, and the Web 

Services Provider 54 is the responder 51 . 

Schemas. Schemas describe the syntax and relationships of data. Each 
service element 116 comprises an associated schema for the data that is 
25 relevant to the service element 116. For example, the profile service 116b 

comprises schema elements 96 which are relevant to a profile 94, such as but 
not limited to a name, an address, and a phone number for a user U. 

System Entity Roles. System Entities may assume one or more roles. . 

30 
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As seen in Figure 3, service descriptors 26 are used to locate a system service 54, 
while service assertions 28 are used as credentials, to access the system service 54. A 
service descriptor 26 typically describes a SOAP endpoint for an identity based system 
service 54. A service assertion 28 is an assertion used as a credential to access an 
5 identity based system service 54. 

Discovery Service Overview. In the identity based service system 10, the personal 
web services 116 for a user U are preferably distributed across multiple web service 
providers 54. Therefore, web service consumers 48 comprise a means for discovering 
10 service locations 54. The discovery device 42 is a personal web service which enables 
system entities 27 to discover a service descriptor 26, given a service name and a 
user's name identifier 174 (FIG. 13), whereby a web service consumer 48 is able to find 
and invoke the web services 54 of a user U. 

15 Figure 5 is a functional block diagram 70 of an identity based service system 10, in 
which a discovery service 42 issues service assertions 28 that are used to invoke 
services 54. Figure 6 is a flow diagram 80 for the access of service 54. 

Because of the pseudonymous identity of users in the identity based service system 10, 
20 web service consumers 48 and web service providers 54 do not have a common name 
for a user U. The identity provider 14 of a user U is the- system entity 27 that maps 
between the disparate namespaces 176,182 (FIG. 13). As seen in Figure 13, the 
discovery service 42, which is hosted by the identity provider 14, provides this 
namespace translation. 

25 

The web service consumer 48 prompts the name translation service, by sending the 
user's name 174a in the WSC-IDP namespace 176, to the identity provider 14. The 
identity provider 14 hands back a user name 174b in the WSP-IDP namespace 182, 
within a format that the web service consumer 48 is blinded to this name, via encryption 
30 184. The encrypted value 184 of the name 174b is preferably different each time the 
name 174a, 174b is used, such that there is no linkable identity information over time 

10 
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between the web service consumer 48 and the web service provider 54. This name 
translation assertion 28 is also preferably time-bound, to prevent long-term use of a 
translated name 174b, and to prevent linking of the actions of a principal 12. 

5 In the identity based service system 10, the user's identity provider 14 always hosts the 
discovery service 42, since the discovery service §4-42 must be aware of the pair-wise 
identifier relationships 174a, 174b between parties 27. 

| In response to a discovery request, the service §4-42 returns 52 a service descriptor 26 
10 that points to a particular web service provider 54. Additionally, a translated name 174b 

and relevant security tokens 186 (FIG. 13) are typically included as well. Some 
| discovery services 54 4 2 enforce user presence requirements on web service 

consumers 48, and/or enforce one or more authorization rules on each web service 

consumer 48. 

15 

The discovery service 54-42 also provides an administrative interface, whereby a set of 
services 116 for a user can be configured. Services may be registered and 
unregistered. (***Please clarify these features as needed***) 

20 Profile Service. Figure 7 is a functional block diagram 90 of profile service 116b (FIG. 
9) principal core information 92. A profile service 90 manages the core personal 
information 92 for a principal 12. The core personal information 92 typically comprises 
a plurality of data types 94a-94n, such as contact data 94a, demographic data 94b, 
and/or core preferences 94n. 

25 

A profile service 116 (FIG. 9) allows principals 12 to create a profile 92, to update 
profile data 94a-94n, and to specify privacy controls 98. Once a user creates a profile 
92, the profile 92 can be used at any of the system web service consumer 48 sites, 
such that principals 12 are not required to re-enter data, such as on a registration form. 

30 
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Figure 8 is a functional block diagram of a profile data entry. Each profile data entry 96 
is typically associated with a collection of metadata 107, sueh-as includinq, but not 
limited to data categories 102, change timestamp information 104, data validation 
information 106, and/or creator informationj 08. 

Data category information 102 allows information to be classified as applicable, such as 
to define a home or business profile. For example, an address can be classified as a 
home and/or a business address. Data categories 102 are typically defined by web 
service providers 54, by web service consumers 48, and/or by principals 12. 

Change timestamps information 104 typically comprises a number 105, e.g. 105a, 
which represents the latest modification time of a particular node and associated 
descendants. 



15 Data validation information 106 comprises an indication of whether the data content 94 
has been validated or not. If the data content 94 is validated, the information may 
preferably comprise what type of validation was performed, and when the validation 
was performed. A web service consumer 48 typically uses metadata 107. 



20 Figure 9 is a schematic view 1 10 of an identity based service system 10 configured on 
a virtual network 112. The virtual network 112, provides a single set 114 of services 
116a-116n, which are provided by one or more contributors 118a-118j. The virtual 
network 112 formed within the identity based service system 10 provides one or more 
core services 116, such as an authentication service 116a, a profile service 116b, an 

25 alert service 116c, and/or a wallet service 116n. The identity based service system 10 
also supports other value-added services 116 for a user, such as a calendar service 
and/or an address book service. The identity based service system 10 provides access 
for a wide variety of web consumer sites 120a-120k, such as large and small business 
sites 120a, 120k. 

30 (120k appears to be cut off in the diagrams; I'm assuming this is the line out of "small 
retail"? 
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As seen in Figure 9, service consumers 48 comprise sites which use services 116 from 
the network 112. As seen through a site 120, the services 116 presented by the virtual 
network 112 preferably look like a single set 114 of services 116, i.e. from a single 
5 provider 1 18 of services, even though the services are typically provided by any number 
of contributors 1 1 8a-1 1 8j. 

The core service provider 118b shown in Figure 9 provides all of the core services 
116a-116n on the virtual network 112. While some basic services, such as a profile 
10 service, are currently available through some Internet providers, such services are 
separate and distinct. In the identity based service system 10, the various services 
1 16a-1 16n are aware of each other and of the virtual network 112 

As seen in Figure 9, the identity based service system 10 preferably comprises a 
15 plurality of service contributors, i.e. vendors 118a-118j. While different 118 vendors 
typically contribute different sets of varying services 116, the source of a service 116 is 
typically transparent to users U as they interact with the recipient sites 120. 

Levels of Trust and Integration. The identity based service system 10 preferably 
20 provides varying levels of trust and integration. For example, as seen in Figure 9, a 
small retail site 120k typically comprises a low level of trust, such that a user U is 
typically asked to confirm transactions, through redirect exchanges with the system 10. 

A larger site 120, such as a large retail site 120a or an auction site 120b, which is 
25 integrated with the network 112 and is able to perform tasks on behalf of the user U, 
e.g. get money from a wallet 116n, typically has a higher level of trust with the system 
10. 

Core service providers 118, such as providers 118a-118j of core services 116, typically 
30 have a high level of trust with the system 10, and are able to perform system functions 
on behalf of a user U. In addition, core service providers 118 which provide 
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authentication 116a have the highest level of service requirements, and inherently 
require the highest level of trust within the system 10. 

Service Invocation. In order to enable interactions between multiple endpoints within 
5 a circle of trust, the discovery service 54 issues service assertions 28 (FIG. 3, FIG. 5) 
that can be used by service consumers 48, such as to access other service providers 
54. 

In some embodiments of the identity based service system 10, messages can be 
10 routed and be transported through multiple hops. Additionally, message-level 
confidentiality is employed for sensitive data in multi-hop cases where confidentiality is 
required. 

The target service provider 54 does not simply consume the service assertion 28. 
15 Relevant policy is enforced to ensure that the service invocation is in line with the 
principal's policies. 

Authentication. Most system services require requester authentication. Additionally, 
the response is authenticated. For example, a user authentication comprises a 
20 determination of the identity 29 of a user U. Online authentication can take many forms, 
such as a stored browser cookie, a user name/password combination, or stronger 
technologies such as smart cards or biometric devices. 

In the identity based service system 10, the user's identity 29 is authenticated, in 
25 accordance with privacy and security policies . The evidence of authentication for a 
user U comprises the user identity 29, in addition to guarantees of authentication. The 
evidence of authentication for a user U refers to stored and/or passed data that 
indicates that a user is authenticated, and which can be interrogated to verify the 
authentication. 

30 
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As an example, web sites often user a stored cookie to provide personalization 
information about their site for the user. However, for e-commerce transactions, that 
same web site will often require the user to explicitly supply a user ID and password. 
Both are authentications, but the ID/password is stronger than the stored cookie. This 
5 allows the site to balance user convenience with its security policies, as needed. 



System Authorization. While user authentication determines the identity 29 of the 
user U, authorization is the process of determining what an authenticated user U is 
allowed to do, and the determination any services and/or entities 27 which are allowed 
10 to act on behalf of the user U. 



For example, a web site that provides access to bank account information may be 
configured to allow only the primary account holder to transfer funds to/from the 
account, but allow all members of the family to view the current account balance. While 
15 each user U is authenticated, only one user U is able to perform authorized activities. 

Another example would be that of a network payment service (or smart wallet) 116n 
(FIG. 9, FIG. 10), which contains credit card information and/or cash account 
information 118. A user U of a wallet service 116n can controllably authorize a web 
20 site service provider 54 to access credit card information and/or cash account 
information. In this case, the user U is authenticated, and authorized to control the 
payment service, while the w e b s i t e service provider is also authenticated, but 
authorized only to access the credit card information. 

25 As shown above, some embodiments of the identity based service system 10 feature a 
| delegation of authorization, wherein a user U is not required too navigate to a payment 
site to authorize a transaction. For example, while a user U shops at a web site 120, 
during a checkout process, a system enabled web site 120 may access the 
payment/wallet service 116n, on behalf of the user U, wherein the user has delegated 

30 authorization to the web site to act on his behalf with the payment service 1 16n. 
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User Identity. In the identity based service system 10, the identity 29 of a user U 
comprises a persona for that user. As seen in Figure 10, a user U can preferably have 
more than one identity 29. For example, a user U can have one identity 29 for personal 
information, another for business information, and a third identity for "anonymous" web 
5 access. 

(The notion of an "authentication record" is introduced for the first time in the paragraph 
following; does it need additional description? A: I see it's below; should it be 
referenced here?) 

The use of multiple identities 29 allows users U to store relevant information associated 
10 with each identity 29, and use or expose the information only as needed. For example, 
| as seen in Figure 110, while "Financial Entity A" corporate credit card information 1 1 8 j 
associated with a business identity 29 and work authentication record 132a is located in 
the wallet 116n, the "Financial Entity A" corporate credit card information 1 1 8 j is not 
located in the wallet 116n associated with the home or personal authentication record 
is 132b 

Similarly, an "anonymous" identity 29 would typically comprise no personally-identifiable 
information, enabling use of that identity 29 in appropriate situations. 

20 Scopes of Authentication. Network authentication occurs when a user's evidence-of- 
authentication (is this 19b?) are issued by a network authentication service 116a (FIG. 
10), and enables a user U to access sites and services on the network 112. This 
enables single-sign on features, wherein all network participants accept network 
evidence-of-authentication, in accordance with their own site policies, e.g. level of 

25 authentication required, and in accordance with user opt-in choices. 

In addition, a local authentication may occur, such as when evidence of authentication 
for a user U is issued by a local site/service, using its own authentication facilities, 
wherein the evidence of authentication is only valid for that specific site or service. A 
30 local authentication does not inherently carry with the user U from one site to another, 
and does not allow the site /service to access network services on behalf of the user U. 

16 
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Some embodiments of the identity based service system 19 provide both forms of 
authentication, whereby the system 10 can be integrated with sites that already have an 
authentication system. 

5 

Requester identity, such as that of a web consumer 48, is established by the inclusion 
of a security token 186 (FIG. 13), which represents the identity of the requestor, and the 
| signing of relevant portions of the message with the key material implied by the security 
token 186. The security token 186 may be an X.509 certificate, a Kerberos ticket, an 
10 SAML assertion, a username & associated password, or any other valid security token 
186, as deemed necessary by the web service provider 54. Additionally, a replay 
protection is preferably employed, such as a nonce-based challenge-response protocol, 
a timestamp included in the signature, or other replay protection mechanism. 

15 The responder's identity can be authenticated, such as by validating that the signature 
of the response (containing the original RequestID) is signed. 

Long-Lived Access to Services. In some alternate system embodiments 10, 
j pursuant to the approval of a user U, the discovery service 54-42 assures long-lived 
20 service assertions to a web service consumer 48, such that the web service consumer 
48 can repeatedly invoke a service at the web service provider 54. Continual 
acceptance of the service assertion 28 at the web service provider 54 is dependent on 
user approval of continued access of the service at the web service provider 54. 

25 However, in system embodiments 10 wherein revocation is desired to be controlled by 
the i d e nt i f ie d identity provider 14 and associated discovery service 5442, the discovery 
service 54-42 prevents long-lived service assertions to a web service consumer 48. 
(***Clarify as needed***) 

30 Service Infrastructure. While current system embodiments 10 comprise a profile 
service (PS) 116 (FIG. 9), the identity based service system 10b preferably comprises a 

17 
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complete services infrastructure, such that the profile service 116, as well as other 
services, may be built on top of web service standards. 

For example, the infrastructure is typically accessible via SOAP over http calls, as 
defined by WSDL descriptions, and use agreed-upon schemas, such that the web 
services infrastructure transparently supports both static and dynamic data. An 
example of static data is a basic profiling service that returns an e-mail address. An 
exaimple of dynamic data is that of an infrastructure served by a calendar service, which 
return calendar appointments. 

S e rv i c e s th e ms el v e s ar e r el at i v el y coars e- gr ai n e d (***P le ase c l ar i fy***) Services, which 
for example may include a user's profile 116b, wallet 116n or calendars/alerts 116c, 
typically are composed of a set of logically related functionality , cont ai ning and contain 
collections of attributes and service calls^ , such as a us e r's prof i l e 1 16b, wal le t 1 16n, or 
ca le ndar/al e rts 1 16c. 

Core Authentication Records. Figure 10 is a functional block diagram of a core 
authentication record (CAR) 132, which is maintained on behalf of a user U, such as by 
the BA^V -ldentitv Provider 14 (F I G. XX) (*** l s th i s shown?***) . The core authentication 
record 132 comprises links 136,140 to sites 120a-120k which are associated through 
the identity based service system 10. The core authentication record 132 is also linked 
to an ACL or other access control mechanism 134 (***Please describe as needed***), 
and to services 138, such as core services 116, as provided by core service providers 
118 , or other web services (not shown) operating within the identity based service 
system 10 . 

Figure 11 is a functional block diagram of multiple core authentication records (CAR) 
132a, 132b, which are maintained on behalf of a user U. Some preferred embodiments 
identity based service system 10 comprise support for multiple identities, i.e. 
personifications or personas, for a user U, wherein a user may interact differently, such 
as within different environments. 
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For example, users U often look at their work personification as different and distinct 
from their home personification, with different sites 120 visited, different credit cards 
11 6n, and sometimes even different alert mechanisms 1 16c. 

5 

As seen in Figure 11, multiple core authentication records (CAR) 132a, 132b are 
preferably supported by the identity based service system 10, whereby a user U 
selectively logs in 18 to one or more core authentication records 132. 

10 The links 136 also preferably include quick-links 140 between accounts 132. Once as 
user U logs in 18 to either account 132, they can switch between the accounts 132, e.g. 
from 132a to 132b, on an as needed or as desired basis, without logging in 18 again. 
For example, as seen in Figure 11, a user U within a work authentication record 132a 
can link 140d to the associated home authentication record 132b for the user U. 

15 Similarly, the user U within a home authentication record 132b can link 140g to the 
associated work authentication record 132a for the user U. 

Figure 12 is a functional block diagram 160 of multiple core authentication records 
(CAR) 132a, 132b, which are maintained on behalf of a user U, based upon the use of 
20 different devices 192a, 192b (FIG. 14). The identity based service system 10 also 
preferably comprises support for multiple devices 192 for a user U, wherein a user logs 
on 18 to the system through any of a plurality devices 192, such as through a desktop 
computer 192a in an office, or through a mobile device 192b at any location. 

25 While the user U may retain a similar identity while operating different devices, such as 
a work identity, the chosen services 138,116 and links 136,140 linked to the 
authentication records 132a, 132b may be chosen or selected as suitable for the device 
192. For example, an extended alert list 116c may be linked to a desktop computer 
192a, while an abbreviated alert list 116c be linked to a mobile device 192b, such as a 

30 personal digital assistant 192b, or an Internet enabled cell phone 192b. Similarly, a 
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wide variety of web site links 140 may be linked to a desktop computer 192a, while only 
a few key web site links 140 may be linked to a mobile device 192b. 

While much of the identity 29, services 116, and/or core providers 118 may be shared 
5 between authentication records 132a, 132b in Figure 12, the authentication records 
132a, 132b provide a customized operating environment for a user U, which is based on 
the device 192 from which the user U logs in 18. 

System Advantages. The Identity based service system 10 provides significant 
10 advantages over conventional identity and service structures. Through the 
establishment of a system identity 29, a user U can quickly provide information as 
needed to system entities 27, while controlling how the information is distributed. The 
use of a secure and centralized identity structure provides controlled authentication and 
authorization of all system entities 27. 

15 

Through the use of detailed identity information, the identity based service system 10 
provides unique value-added services, such as fast sign-in 18, a customized personal 
network environment, and quick links 140 to existing and new associated web service 
providers 120. 

20 

System Operation. Figure 14 is a schematic view 190 of a user logging onto a first 
service provider site 120, wherein the user does not currently have a system identity 29. 
In the process of registering as a user at the site 120, the user typically establishes a 
user name 492— 196 and password 49 4198 , and enters appropriate information to 
25 operate within the site 120, such as name, address, and/or credit information 96. 

Figure 15 is a second view 200 of operation for an identity based service system 10, 
wherein the user is asked if an identity based service system identity 174 is desired, to 
easily establish relationships with other providers 120, such as through selectable 
30 member site links 202, and/or to establish or manage system services 116, e.g. such as 



20 



Attorney Docket No. AOL0091 



to establish a profile service 116b or a wallet service 116n, through selectable service 
links 204. 

Figure 16 is a third view 210 of operation for an identity based service system 10, in 
5 which a system identity 29 is established at an identity provider 14. The information 
gathered from the first site 120 is securely stored in the identity provider 14. The user U 
may easily chose one or more member site links 202 and/or service links 204, typically 
from an identity service selection screen 206. 

10 Although the identity based service system and its methods of use are described herein 
in connection with personal computers, mobile devices, and other microprocessor- 
based devices, such as portable digital assistants or network enabled cell phones, the 
apparatus and techniques can be implemented for a wide variety of electronic devices 
and systems, or any combination thereof, as desired. 



15 



20 



25 



30 



As well, while the identity based service system and its methods of use are described 
herein in connection with interaction between a principal and a network through a 
device, the use of identity based services can be implemented for a wide variety of 
electronic devices and networks or any combination thereof, as desired. 

Accordingly, although the invention has been described in detail with reference to a 
particular preferred embodiment, persons possessing ordinary skill in the art to which 
this invention pertains will appreciate that various modifications and enhancements may 
be made without departing from the spirit and scope of the claims that follow. 

Other comments from David Wexelblat 

the one big issue I have is that "core services" is defined as authentication, profile, 
wallet calendar and alerts. I think this is an overly-broad definition, one that would be 
susceptible to being implemented around (e.g. someone implements what we've 
described, but without calendar, it isn't the service as we've described). For what we are 
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trying to define here, only authentication, and possibly profile, would be considered 
"core" and everything else applications on top of these core services. With the definition 
of "core authentication record" and "discovery service". I don't think profile is even core. 

I think the ambiguity arose from the set of services initially planned for Magic Carpet 
Network V1. Those services were core to business, not core to the technology or 
implementation thereof. 
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CLAIMS 

What is claimed is: 

5 1. An identity based service system, comprising: 

at least one principal comprising at least one identity comprising user information 
an identity provider for managing at least one identity for the principal, and for 
authenticating the principal; and 

a system entity which is accessible by the principal, based on an authentication 
10 of the principal by the identity provider, and based on retrieval of at least a portion of 
user information from the identity provider. 

2. The identity based service system of Claim 1, further comprising: 

at least one core service associated with the system and related to at least a 
15 portion of the user information. 

3. The identity based service system of Claim 2, wherein the core service is accessible 
by the user, based on an authentication of the principal by the identity provider. 

20 4. The identity based service system of Claim 2, wherein the core service is accessible 
by the system entity, based on an authentication of the principal by the identity provider. 

5. The identity based service system of Claim 2, wherein the core service is associated 
with one or more core service providers. 

25 

6. The identity based service system of Claim 2, wherein the core service comprises 
any of an authentication service, a profile service, an alert service, a calendar service, 
and a wallet service. 
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7. The identity based service system of Claim 1, wherein the identity provider further 
comprises means for translating namespaces, such that a user identity of a principal in 
a first namespace is translatable to a user identity in a second namespace. 

5 8. The identity based service system of Claim 7, wherein the user identity in the second 
namespace is encrypted. 

9. The identity based service system of Claim 7, wherein the user identity in the second 
namespace is time-bound. 

10. The identity based service system of Claim 1, further comprising: 
at least one core authentication record associated with the identity, comprising 

any of services and links associated with the identity. 

11. An identity based service system, comprising: 
an identity module for managing an identity for a user; 

a discovery module associated with the identity module and adapted to receive a 
user name identifier associated with the user and a service name assoc ia t e d w i th th e 
usef known to the system : 

means for discovering a service descriptor for the user, based on a received 
name identifier and a service name; and 

whereby at least one web service is accessible, based upon the discovered 
service descriptor and the name identifier. 

25 12. The identity based service system of Claim 1 1 , further comprising: 

at least one core service associated with the system and related to the user. 

13. The identity based service system of Claim 12, wherein the core service is 
accessible by the user, based on a system authentication of the principal at the identity 
30 module. 
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14. The identity based service system of Claim 12, wherein the core service is 
accessible by a system entity, based on an authentication of the principal at the identity 
module. 

5 15. The identity based service system of Claim 12, wherein the core service is 
associated with one or more core service providers. 

16. The identity based service system of Claim 12, wherein the core service comprises 
any of an authentication service, a profile service, an alert service, a calendar service, 

10 and a wallet service. 

17. The identity based service system of Claim 1 1 , wherein the identity module further 
comprises means for translating namespaces, such that a user identity of a principal in 
a first namespace is translatable to a user identity in a second namespace. 

15 

18. The identity based service system of Claim 17, wherein the user identity in the 
second namespace is encrypted. 

19. The identity based service system of Claim 17, wherein the user identity in the 
20 second namespace is time-bound. 

20. The identity based service system of Claim 1 (is this claim 1 or claim 11?) , further 
comprising: 

at least one core authentication record associated with the identity, comprising 
25 any of services and links associated with the identity. 

21. The system of Claim 11, wherein the principal is located at a device linked to the 
identity based service system. 

30 22. An identity based service process, comprising: 

providing an identity module for managing an identity for a user; 
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receiving a user name identifier associated with the user and a service name 
assoc i at e d w i th th e us e r known to the system ; 

discovering a service descriptor for the user, based on a received name identifier 
and a service name; and 
5 controllably authenticating access to a service, based upon the receipt of the 

discovered service descriptor and the name identifier. 

23. The process of Claim 22, further comprising the step of: 

establishing at least one core service associated with the system and related to 
10 the user. 

24. The process of Claim 23, wherein the core service is accessible by the user, based 
on a system authentication of the principal at the identity module. 

is 25. The process of Claim 23, wherein the core service is accessible by a system entity, 
based on an authentication of the principal at the identity module. 

26. The process of Claim 23, wherein the core service is associated with one or more 
core service providers. 

20 

27. The process of Claim 23, wherein the core service comprises any of an 
authentication service, a profile service, an alert service, a calendar service, and a 
wallet service. 

25 28. The process of Claim 22, further comprising the step of: 

translating namespaces, such that a user identity of a principal in a first 
namespace is translated to a user identity in a second namespace. 



29. The process of Claim 28, further comprising the step of: 
30 encrypting the user identity in the second namespace. 
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30. The process of Claim 22, wherein the user identity in the second namespace is 
time-bound. 

31 . The process of Claim 22, further comprising the step of: 

5 associating at least one core authentication record with the identity, comprising 

any of services and links associated with the identity. 

32. A process, comprising the steps of: 

providing an identity provider networked to a service having a service name; 
10 establishing an identity at the identity provider for a principal, comprising 

information and a name identifier for a user; 

establishing a link between the principal and the service by the identity provider, 
based upon a receipt of a name identifier and a service name. 
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Identity Based Service System 



15 April 



ABSTRACT OF THE DISCLOSURE 



An identity based service system is provided, in which an identity is created and 
managed for a user or principal, such that at least a portion of the identity is 
available to use between one or more system entities. A discovery service 
enables a system entity to discover a service descriptor, given a service name 
and a name identifier of the user, whereby system entities can find and invoke 
the user's other personal web services. The discovery service preferably 
provides a translation between a plurality of namespaces, to prevent linkable 
identity information over time between system entities. 
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Wednesday, July 23, 2003 



Re: AOL0091 Patent Draft 'Comments due ASAPI 



Page: 1 



Subject: Re: AOL0091 Patent Draft *Comments due ASAP! 
Date: Wed, 23 Jul 2003 13:24:15 -0400 
From: "Conor P. Cahill" <concahil l@aol.com> 
Organization: America Online, Inc. 

To: "Jessica Pallach" <jessic a@glenn-law.com> 
References: 1,2,3 



Jessica Pallach wrote: 

> Thanks Edwin and David. I have forwarded your comments to Don for 

> incorporation. He will contact you if he has any questions. 

> ^ 

> As soon as I hear back from Conor and Jeromy with their address info, 

> I can 

> prepare the formals papers for signatures. PS, do you know their info or 

> another way to contact them? 
> 

> Thank you for your cooperation! 

The law firm should have all my info.... This isn't my first patent 
application filled though Glenn Law. 

Anyway ... 

Conor P. Cahill 
38580 Daymont Lane 
Waterford, VA 20197 

US Citizen. 

If it matters, I have dual citizenship (Ireland and US) born in US to 
Irish immigrants. I have always claimed US citizenship in prior 
applications. 

Conor 
> 

> -Jessica 
> 

> 
> 

> Edwin Aoki wrote: 
> 

> > Jessica, 

> > 

> > I apologize for the delay; I was out of town for the past three weeks 

> > and am just now getting through the backlog of email. (Of course, I do 

> > recognize that I've had this draft for longer than that). I've 

> included 

> > redlines in the attached document. Some are clarifications (as 

> > requested) and others are some corrections to figure numbers based 

> on my 

> > reading of the text. I would appreciate it if yu could attempt to 

> > verify that I interpreted the text correctly in making the corrections; 

> > this is not simple stuff, and it's been a while since we'd looked at 

> > some of this system design. 

> > 

> > Thanks again for your effort to make this understandable - or at least 

> > understandable to the folks over at the PTO. :-) 

> > 

> > Let me know if you have any further questions, 

> > -Edwin 

> > 

IMAP://192.168.t.2?fetch>UID>/INBOX>1045 
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Wednesday, July 23, 2003 



Re: AOL0091 Signature forms! 



Page: 1 



Subject: Re: AOL0091 Signature forms! 
Date: Wed, 23 Jul 2003 16:34:01 -0700 
From: Jessica PaJlach <jessica@glenn-law.com> 
Organization: Glenn Patent Group 

To: "Conor P. Cahill" <concahill@aol.com> . "Jim A. Roskind" <iar@netseape.com> . 
AOL-David Wexelblat <davidwexelblat@aol.coro> . 
AOL-Edwin Aoki <edwinaoki@ aol.net> . Jeromy Carriere <sjcarriere@hot 
Cfois Tpomey <ctoomey @ netsc3p5.com> 
References: 1,2,3,4,5 

I just found out about an additional inventor. Please dis 
previous forms and sign the attached! Again, sorry! 

Chris - the application is attached for review. 

-Jessica 



"Conor P. Cahill" wrote: 




Jessica Pallach wrote: 



> 
> 

> > 

> > 

> > 

> > 

> > 

> > 
> 

> That 's fine, 
> 

> Conor 




Conor, 

No problem, I can fix the forms. I'm going off the list of inventors 
on the disclosure form in the file. Obviously, that's not correct. Is 
there anyone else that should be included? Is the order of inventors 
ok as-is (adding Jim to the bottom)? 

Chris Toomey is the last that I am aware of. 



Jessica L. Pallach 

Patent Administrator / IP Database Manager 

Glenn Patent Group 
3475 Edison Way, Suite L 
Menlo Park, CA 94025 
650-474-8400 
650-474-8401 (Fax) 
jessica@glenn-law. com 



This message is intended only for the individual to whom it is addressed 
and may contain information that is confidential, privileged, or otherwise 
exempt from disclosure under applicable law. If you are not the individual 
to whom this message is addressed, you are advised that any use, copying, 
or disclosure of this message or the contents thereof is without permission 
and contrary to law. If you receive this message in error, please call 
650-474-8400. 





Name: Assignmentdoc 




Type: Microsoft Word Document (application/msword) 


[j|Assignrnent.dop 


Encoding: base64 




Description: Unknown Document 




Download Status: Not downloaded with message 
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Re: AOL0091 Signature formsl 





Name: Dec:POA.doc 




Type: Microsoft Word Document (application/msword) 


[i^Dec:POA.doc 


Encoding: base64 




Description: Unknown Document 




Download Status: Not downloaded with message 
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From: Don Hendricks <donhdesign@earthlink.net> 

Subject; AOL0091 Second Patent Draft for Comments ASAP 

Date: August 14, 2003 9:20:25 AM PDT 
To: Conor Cahill <ConCahill@aol.com>, Edwin Aoki <edwinaoki@aol.net>, David Wexelblat <davidwexe!blat@aoi.com>, 

Jeromy Carriere <j@thecarrieres.com>, Jeromy Carriere <sjcarriere@hotmail.com> 
$ 2 Attachments, 255 KB 

Conor, Edwin, David, Jeromy, 

Attached is a second draft of the application and drawings for this application, which incorporates the detailed comments I 
received from Edwin, and the general comments ! received from David. 

I also made several other corrections, and added supporting paragraphs, particularly in reference to Figures 1-6. I also made 
several corrections in the Figures, and added identity reference characters (e.g. 29a,29b) associated with core authentication 
records (FIG. 10, FIG. 11). 

Please make your final review, and send your red-lined version, or approval to file, by Monday^j&jgijst 19. 

Thanks, 

Don Hendricks 

Patent Agent 

(831) 656-0598 Ph 

(831) 656-0598 Fax 

donhdesign@earthlink.net 

for Glenn Patent Group 
3475 Edison Way, Suite L 
Menlo Park, CA 94025 
650-474-8400 
650-474-8401 (Fax) 

This message is intended only for the individual to whom it is addressed 
and may contain information that is confidential, privileged, or 
otherwise exempt from disclosure under applicable law. If you are not 
the individual to whom this message is addressed, you are advised that 
any use, copying, or disclosure of this message or the contents thereof 
is without permission and contrary to law. If you receive this message 
in error, please call 650-474-8400. 

•V. 

API nogi.ADD.V2.8.14.03 (91.8 KB) AOL009LPwqs.v2.pdf (X63 KB) 



From: Edwin Aoki <edwinaoki@aol.net> 
Subject; Re: AOL0091 Second Patent Draft for Comments ASAP 




Date: August 14, 2003 9:34:15 AM PDT 
To: Don Hendricks <donhdesign@earthlink.net> 

Cc: Conor Cahili <ConCahill@aol.com>, David Wexelblat <davidwexelblat@ao!.com>, Jeromy Carriere 
<j@thecarrieres.com>, Jeromy Carriere <sjcarriere@hotmail.com>, jar@roskind.com, Chris Toomey 
<ctoomey@aol.com> 

Don, 

I am forwarding your request to Jim Roskind and Chris Toomey, two additional inventors who were inadvertently left off of the 
original message. Jim can be reached at jar@roskind.com, and Chris at ctoomey@aoi.com. Both are copied on this message. 

Thanks, 
-Edwin 



Don Hendricks wrote: 
Conor, Edwin, David, Jeromy, 

Attached is a second draft of the application and drawings for this application, which incorporates the detailed comments I 
received from Edwin, and the general comments I received from David. 

I also made several other corrections, and added supporting paragraphs, particularly in reference to Figures 1-6. 1 also made 
several corrections in the Figures, and added identity reference characters (e.g. 29a,29b) associated with core authentication 
records(FIG.10,FIG.11). 

Please make your final review, and send your red-lined version, or approval to file, by .Monday, August 18_. 

Thanks, 

Don Hendricks 

Patent Agent 

(831) 656-0598 Ph 

(831) 656-0598 Fax 

donhdesign@earthlink.net 

for Glenn Patent Group 
3475 Edison Way, Suite L 
Menlo Park, CA 94025 
650-474-8400 
650-474-8401 (Fax) 

This message is Intended only for the individual to whom it is addressed 
and may contain information that is confidential, privileged, or 
otherwise exempt from disclosure under applicable law. If you are not 
the individual to whom this message is addressed, you are advised that 
any use, copying, or disclosure of this message or the contents thereof 
is without permission and contrary to law. If you receive this message 
in error, please call 650-474-8400. 



Tuesday, September 2, 2003 



AOL0091 . 



Rnal Draft lor filing & Inventor Disclosure Form 



Pafle 1 



Subject: AOL0091 - Final Draft for filing & Inventor Disclosure Form 
Date: Fri, 29 Aug 2003 09:53:03 -0700 
From: Don Hendrick s <donhdesign@earthlink.net> 
To: Jessiqa@glenn-Iaw.com 



Jessica 

Here's the final draft of the Application for this project. I also filled out the Inventor Disclosure form, based on 
the information & documents received from the inventors. I Fedexed 3 sets of formal drawings (16 Figures on 16 
sheets) to you, for delivery this AM. 

Also attached if the last email from Conor Cahill with his approval to file. FYI- Conor was the only inventor to 
review and approve the final drafts of the Application (3rd draft) & Figures (4th draft). 

If there's anything else I need to do on this, please let me know. 



Thanks, 
Don 

§)Part 1.1.2 



Type: Macintosh File 
Download Status: Not downloaded with message 



I^I Part 1.1,4 



Type: Macintosh File 
Download Status: Not downloaded with message 



From: "Conor P. Cahill" <concahill@aol.com> 

Date: Fri Aug 29, 2003 08:53:15 AM US/Pacific 

To: "Don Hendricks" <donhdesign@earthlink.net> 

Subject: Re: AOL0091 Fourth Draft of Figures for Comments ASAP 

Don Hendricks wrote on 8/28/2003, 4:34 PM: 

Conor, 

I'm assuming from your last e-mail that both the application and 
drawings are acceptable for filing. 

Yes, that is correct. 

I'll also update the AOL Inventor Disclosure Document; if other 
information is requested for the document, I may contact you as needed. 

Ok. 



Conor 
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Using Smart Clients to Build Scalable Services 

Chad Yoshikawa, Brent Chun, Paul Eastham, 
Amin Vahdat, Thomas Anderson, and David Culler 

Computer Science Division 
University of California 
Berkeley, CA 94720 

Abstract 

Individual machines are no longer sufficient to handle the offered load to many Internet sites. To use multiple 
machines for scalable performance, load balancing, fault transparency, and backward compatibility with URL 
naming must be addressed. A number of approaches have been developed to provide transparent access to multi- 
server Internet services including http redirect, DNS aliasing, Magic Routers, and Active Networks. Recently 
however, portable Java code and lightly loaded client machines allow the migration of certain service functionality 
onto the client. In this paper, we argue that in many instances, a client-side approach to providing transparent access 
to Internet services provides increased flexibility and performance over the existing solutions. We describe the 
design and implementation of Smart Clients and show how our system can be used to provide transparent access to 
scalable and/or highly available network services, including prototypes for: telnet, ftp, and an Internet chat 
application. 
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